Bo Victor Thomsen

Hvad man i ungdommen nemmer...

I 1985 var alt ellers klappet og klart til at indføre Datalære som fag på ungdomsudannelserne og undervisningsministeren var sådan set til sinds at skrive under.</p>
<p>Så kom der et valg, en ny minister og nogle "venner" der forklarede ham, at det næringslivet havde brug for, var folk der kunne Tekstbehandling og Rengeark. Det der "datalære" var rent spild af tid og penge.</p>
<p>Det er formodentlig den dyreste IT bommert i Danmarks historie...</p>
<p>

Samme regering lavede nogenlunde samtidigt også en ekstra "geni streg" - sansynligvis foranlediget af de samme "venner":

På det tidspunkt sad der ofte et par uddannede programmører i hver offentlig styrelse - dels som system managers på minicomputere (eks. DEC VAX) og dels til udvikling og vedligeholdelse af lokale programsystemer.

Regeringen udstedte et "dekret" om at systemudvikling nu skulle foregå via "kommercielle aktører" (eller noget i den retning). Så programmørerne blev gået og eksterne firmaer blev hentet ind i konkurrencens hellige navn.

Programmørene var sådan set ligeglade. De blev ansat i de private firmaer til en hel anden løn og fortsatte med at lave det samme arbejde til en hel anden pris.

Men problemet var, at pludselig havde de enkelte styrelser overhovedet ingen (nogenlunde) kvalificeret hjælp ansat længere til at frasortere det værste sælger tekno-vrøvl

Med et et kendt resultat. Det var ikke fordi, der ikke blev lavet nogle værre brølere før den tid. Det blev bare meget, meget værre

4. november 2021 kl. 17:39
Hvad man i ungdommen nemmer...

Hej Bo! Eller: Lur mit liv...

Hej Nis - Det var ikke for at "stalke" dig, men blot fordi din kommentar gav nogle hukommelses-glimt hos mig fra min tid som programmør i Fredningsstyrelsen og sidenhen resten af Miljøministeriet.

Og det var naturligvis ZETA, jeg tænkte på og ikke ZEUS. Jeg tror faktisk vi har snakket om systemet tilbage den gang i start-80'erne, fordi jeg sad og lavede nogenlunde det samme type arbejde - kortgenerering/GIS - i Fredningsstyrelsen.

4. november 2021 kl. 12:43
Hvad man i ungdommen nemmer...

I 1982 var jeg som grøn VAX-programmør ude for at udtegning af et landkort lagret i en DBMS database tog et kvarter (15 minutter). Jeg denormaliserede databassen og så tog det samme kort 15 sekunder.

Det er ikke hver dag, man ser kommentarer vedr. ZEUS databasen hos DGU. Men et eller andet skulle jo man bruge den VAX 780'er med RDMS til hos DGU. Gætter jeg mig til ?? :-)

Men generelt set: Hvis Danmarks stab af jurister og cand. politter ansat i stats- og kommunal-administrationen (eller politikere med samme type uddannelse) havde fået den mindste gnist af datalære ind sammen det øvrige pensum havde vi sandsynligvis kunne undgå en lang række nationale og kommunale IT katastrofer.

Simpelthen fordi de ville være udstyret med et fundamentalt gylle filter til at opfange mange af de temmeligt forblommede udsagn, som div. sælgere af IT løsninger kan finde på at fyre af.

4. november 2021 kl. 08:28
Vestager bliver kommissær med ansvar for det digitale område

Man skal måske lige huske på at Magrethe Vestager var (er?) stor tilhæger af "elektroniske valg" for nogle år siden.

https://www.berlingske.dk/politik/vestager-vil-have-elektroniske-valg

Også selv om stort alle uafhængige eksperter på området advarede om at teknologien slet ikke var moden til dette skridt.

Når det er sagt, har Magrethe Vestager vist sig at have en voldsom stor gennemslagskraft i EU systemet i hendes tidligere rolle som konkurrence-kommisær.

Man kan håbe hun også bruger denne kraft til gode formål på det digitale område. Og at hun skiftet mening om elektroniske valg

10. september 2019 kl. 18:15
Regeringen positiv over for CBS-forslag om helt at droppe offentlig it-udvikling

Efter alle klaphattene, politiske og andre, har drukket af den.

Jeg vil undlade at ridse alle de argumenter op, som første artikel (https://www.version2.dk/artikel/it-professor-flyt-de-statslige-it-projekter-privat-selskab-1058839) om dette emne fik på banen i kommetarsporet. Blot nævne et par enkelte:

  1. Situationen skal altså gøres "bedre" ved at de firmaer, som i den nuværende situation gang på gang leverer noget IT-bæ, nu også skal drive disse systemer. Dette er forbi enhver for for normal logik.
  2. Hvis man rent faktisk gennemførte denne beslutning ville udgifterne til at drive IT stige astronomisk i det offentlige, fordi man som kunde ville være totalt i lommen på driftselskabet. Disse firmaer ville kunne selv bestemme fakturaens størrelse.
  3. Der findes masser af velfungerende IT systemer i det offentlige. Dem hører man sjældent om, fordi det ikke giver de store overskrifter i dagspressen. En del af disse stammer i øvrigt fra tid, hvor det offentlige faktisk selv udviklede systemer vha. "programmører" (som det hed den gang) ansat i det offentlige.

Hvad med at prøve en anden vej, hvor man bryder mastodont systemerne op i mindre overskuelige bidder og kræver at leveret software er open source, således at det rent faktisk er muligt at skifte leverandør hvis dette viser sig at være nødvendigt

23. januar 2017 kl. 07:51
Kommentar: Derfor er en it-havarikommission ikke løsningen

Men når det gælder de tekniske bidrag til problemerne, så får vi ikke ret meget ud af at kende dem. Fra et projekt får en kravspecifikation til det endegyldigt viser sig at være gået, og it-havarikommissionen har en rapport klar, så er afstanden i tid for lang. Polsag var 8 år undervejs - der når simpelthen at ske for meget, selv med de involverede teknologier, i mellemtiden til, at vi kan bruge erfaringer som mit tænkte eksempel til ret meget.

Du har ret mht. til det valgte (teknik) eksempel: At dims A ver. x spillede dårligt sammen med dims B ver. Y for 10 år siden vil i mange tilfælde være urelevant. Men der er så mange andre (og vigtigere) årsager til et havari: Som f.eks. den valgte udviklingsmetode, projektstyringen vedr. udvikling, opsplitning af gigant projekter i overskuelige, mindre bidder, iterativ kontrol af del-leverancer, brugerinddragelse (eller mangel på samme) osv. osv. - aspekter, som ikke ændrer sig synderligt over lange perioder. Disse problemer ville en havari kommision kunne belyse og i sidste ende afhjælpe.

12. august 2015 kl. 18:55
Kommentar: Derfor er en it-havarikommission ikke løsningen

</p>
<p>Ja, vi kan måske lære, at det ikke går (i et tænkt eksempel) at kombinere Scanjours ESDH med en Microsoft Biztalk Server 2006 og Oracle DB 9, hvis man vil have lave svartider.

Hvis den ovenstående kombination rent faktisk var årsag til lange svartider og et IT-havari er det da en vigtig oplysning at få ud af en "havari-kommisions-analyse". Det er jo ikke alle kombinationer, som er så usædvanlige som den valgte strå-mand.

Hen af vejen vil det sandsynligsvis være muligt at finde en række specifikke årsagssammenhænge til IT-havarier. Det er vel basalt set den egentlige årsag til at nedsætte kommisionen ...

12. august 2015 kl. 14:15
Forældre fandt banale sikkerhedshuller i udbredt it-system til børnehaver

http://en.wikipedia.org/wiki/Peter_Principle

Jobsikring 101 starter med at tage sit job alvorligt. Ellers må man overlade det til andre, som har den nødvendige kompetence og vilje til at gøre tingene bedre.

11. juni 2015 kl. 08:18
Hvad skal vi lære unge om at gennemføre IT projekter?

Amen til det -

Og så venter vi 10 - 15 år, indtil de har erstattet de primus-motor-personer i det offentlige, som har bestilt og "gennemført" Amanda, Polsag, ProAsk og andre Titanic-lignende projekter i det offentlige.

Min egne 10 øre: Hav fokus på de grundliggende data og sammenhængen/tilgangen/snitfladen til disse - Hvis det er i orden kan du oftest udskifte brugerfladen til noget, der lugter mindre dårligt.

24. maj 2015 kl. 13:41
ODF 1.2 i ISO (PAS submission)

Der er stadig intet belæg for den påstand.

Det eneste, vi kan være enige om vedrørende dette punkt, er at være uenige. Vi kan genoptage diskussionen om dette emne om et par år, og bruge England som en testcase.

2. august 2014 kl. 09:32
ODF 1.2 i ISO (PAS submission)

De må være billigt til salg, for der er massiv empirisk evidens for, at god interoperabilitet til Microsoft Office giver bedre konkurrence.

Der er massiv empirisk evidens for, at god interoperabilitet til Microsoft Office's dokumentformat giver andre office programmer en mulighed for at konkurrere. Fordi MS-office's dokumentformat i en mindre menneskealder har været de-facto standarden for danske myndigheder. Hvis dokumentformatet hos myndighederne blev skiftet ud til et andet format, ville konkurrencesituationen ændre sig drastisk. En ofte afgørende faktor for udskiftning af selv MS-office (til en nyere version) er fordi samarbejdspartnere eller andre afdelinger i myndigheden er begyndt at benytte en nyere version af MS-office og derfor aflever dokumenter i et andet format end tidligere.

1. august 2014 kl. 15:14
ODF 1.2 i ISO (PAS submission)

Nej, dette er IKKE en idéel situation. For hvad skal kontorpakkerne gøre af resten af den funktionalitet, der er anvendt? Den er pinedød nødt til at blive persisteret et eller andet sted. Tanken om et "Core dokumentformat" er død - stendød, og det genopliver den ikke at blive ved med at nævne den.

Der er forskel på et udvekslingsformat mellem forskellige brugere og et format til internt og eget brug. At vi diskuterer brugen af ODF/OOXML som udvekslings standarder er en nødsituation opstået fordi der ikke findes et indlysende rigtigt udvekslings standard. Både ODF og OOXML er "fulde" dokumentstandarder, som ikke er optimale som udvekslingsstandard.

Hvorfor bliver du ved med at holde fast i dine "meget begrænsede" forsøg i stedet for at lytte til mig?

Jeg lytter skam til dig - og en lang række andre eksperter på området. I er på ingen måde enige. Udover det, har jeg selv lavet nogle simple undersøgelser. Det tror jeg, er mere end de fleste interessenter har gjort.

Jeg tror ikke på, at Microsoft Office skulle blive mere fordelagtigt stillet ved valg af OOXML

Hvis du mener at Microsoft Office ikke står bedre, hvis man kun benytter OOXML som udvekslingsformat, så har jeg et tårn i Paris og en bro i New York, jeg gerne vil sælge til dig. Der er en 100 % topologisk sammenhæng (NB topologisk - ikke topgrafisk) mellem dokumentets interne repræsentation/funktioner i MS-Office og OOXML repræsentationen. Dette kan aldrig opnås med andre Office programmer (Undtaget et "ikke MS-Office" program, som fra bunden fra bygget op omkring brugen af OOXML som "native" format). Selvfølgelig vil det stille MS-Office bedre end andre office programmer. Men naturligvis er dette kun én blandt en lang række faktorer som man skal tage hensyn til ved valg af office system. Men jeg synes, vi skal udsætte denne del af diskussionen indtil der foreligger nogle tal fra England efter et par år med ODF som dokumentstandard. Jeg gætter på, at der vil være sket et klart måleligt skift i brugen af office programmer væk fra MS-Office over mod Libre-/OpenOffice og andre "native"-ODF baserede programmer.

1. august 2014 kl. 14:04
ODF 1.2 i ISO (PAS submission)

Dette jo en tautologi - uanset antallet af valgte formater. Ved valg af 0 eller 1 format, vil du også opleve bøvl. Hvordan kan du konkludere, at bøvlet ved 1 format vil være mindre end bøvlet ved 2 formater? Som markedet er nu, så tvinger du ved valg af 1 format (her, ODF) til statsgaranteret bøvl i 90% af de tilfælde, hvor et dokument udveksles - nemlig fra MSO til MSO. Hvis du havde tilladt, at MSO kunne sende i OOXML til MSO, så var disse 90% bøvl kraftigt minimeret med et trylleslag.

Jesper - I stedet for at svare enkeltvis på hver af dine argumenter vil jeg tillade mig at ridse min egen argumentation op og forsøge at svare på dine argumenter.

  • De offentlige myndigheder bør benytte eet format til udveksling af tekst. At benytte to eller flere indbyrdes inkompatible dokumentformater vil medføre enten fortolknings eller konverteringsproblemer hos modtager, når modtager og afsender benytter hvert sin tekstbehandler. I sin yderste konsekvens kan modtager - myndigheden tvinges til at opretholde to funktionelt ens behandlingssystemer, men med hver sit tekstbehandler i bunden (Hvis de to formater er så forskellige, at der ikke kan laves en rimelig troværdig automatisk to - vejs konvertering mellem formaterne).

  • Ved at have eet format tvinges alle program-leverandører til at opnå optimal support for det valgte format. Sagt på en anden måde: Man lægger ansvaret og besværet med konvertering mellem den ene udvekslingsformat og internt format for tekstbehandleren over hos leverandøren.

  • Ideelt set burde man have det simplest mulige redigérbare, leverandøruahængige format. I mangel på dette, må man vælge mellem de to formater, der er fremherskende på markedet.

  • Mine egne ad-hoc undersøgelser får mig pt. til at hælde mod ODF. Hvis jeg lige pludselig stod i en situation, at jeg havde reel indflydelse på valget af format, ville jeg selvfølgelig afgøre mit valg på helt anderledes grundige undersøgelser. Og måske komme til en anden konklusion.

  • Valget af standard format vil give den tekstbehandler, som benytter udvekslingsformatet internt "vind i sejlene". Et helt åbenlyst scenarie er, at myndighederne benytter udvekslingsformatet som internt format. Dette vil selvfølgelig give en vis konkurrence fordel til den gruppe af tekstbehandlere, som benytter formatet internt. Nu er det jo umuligt at spå 100% korrekt om fremtiden. Men vi kan jo vende tilbage til dette punkt om et par år, når/hvis England får gennemført deres beslutning om at bruge ODF som format og se på markedsandele for tekstbehandlere i England.

  • Jeg er personligt ligeglad hvilken tekstbehandler myndighederne benytter. Myndighederne vil forhåbentlig foretage en række rationelle valg mht. softwarevalg ud fra deres givne situation.

Og så slut for denne gang - Jeg har også et arbejde, der skal passes.

31. juli 2014 kl. 16:56
ODF 1.2 i ISO (PAS submission)

Er din konklusion så ikke ret ligegyldig (undskyld mig)?

Tjah, i så fald er der en rigtig lang række af blog indlæg - inklusive det oprindelige blogindlæg der er udgangspunktet for denne diskussion - som er inderligt ligegyldige. Jeg har skrevet om mine betragtninger vedr. debatten om OOXML/ODF og antallet af standarder ud fra min egen synsvinkel som udvikler af systemer til behandling af tekst dokumenter for offentlige myndigheder. Du skriver blog indlæg ud fra din egen position. Vi uden tvivl uenige om de fleste punkter i denne debat.

31. juli 2014 kl. 14:28
ODF 1.2 i ISO (PAS submission)

Nej, det kunne jo også være, at kineserne har nemmere ved konverteringen, fordi deres standard har et større syntaktisk/semantisk overlap med OOXML end ODF har. Min pointe var, at en repræsentant fra en side kommer med en enøjet udtalelse på et usikkert grundlag om den anden side - definitionen på et partsindlæg.

31. juli 2014 kl. 14:18
ODF 1.2 i ISO (PAS submission)

Haha ... ja, dette er hvad Jim Thatcher (MS repræsentant i udvalget for OOXML i ISO) skrev for nyligt på mail listen for gruppen...

Det kan man vist kalde ur-definitionen på et partsindlæg: En part kalder kalder sin modpart en klaphat. Jeg tror ikke at nogen parter i den generelle debat vedr. OOXML/ODF kan sige sig fri for at have lavet både faktuelt rigtige og forkerte udtalelser.

31. juli 2014 kl. 13:42
ODF 1.2 i ISO (PAS submission)

der burde være en uvildig standard for dokumentudveksling og persistens.

Jeg er fuldkommen enig med dig mht. til dette. Der burde findes et leverandør uafhængigt - og redigerbart - format, som indeholder et tilstrækkeligt minimum af funktioner/elementer.

For os der har forsøgt i flere år at benytte OpenOffice og derefter LibreOffice, for så at vende tilbage til MS Office, alene af den grund at det er et langt bedre og mere integreret produkt. Er situationen uændret. Dog er da det en skam hvis man skal forkrøble sit output ved at man tvinges til at gemme det i ODF.

Jeg har ikke lyst til debattere valg af office produkt. Det er op til den enkelte person at have et favoritprodukt. Jeg er f.eks. godt tilfreds med LibreOffice (og hader "Ribbon" interfacet i MS-Office 2007+) YMMV.

Friheden til at vælge er da opfyldt, hvis man selv kan vælge hvilket format man vil sende til f.eks. en offentlig myndighed, og man ikke skal være tvunget til en eller anden ensretning.

Hvis man smertefrit, automatisk og reversibelt kunne konvertere mellem de valgte standardformater har du helt ret. Dette er ikke tilfældet. Dette efterlader de myndigheder, som modtager tekstdata i et for dem "ikke native" format med et valg mellem pest eller kolera : Enten at skulle fortage en < 100% korrekt formattering til deres eget interne format (med risiko for fejlfortolkning af dokumentet) eller duplikere samtlige funktioner i deres sagsbehandlings systemer, således dette understøtter alle standardformaterne.

Slutteligt mht. til mit personlige vurdering af de to formater: For et par år siden lavede jeg en lille prøve. Jeg oprettede 2 dokumenter. Et ODF dokument i LibreOffice og et OOXML dokument i MS-Office. De to dokumenter var indholdsmæssigt stort set ens; relativt komplekse og med en række forskellige elementer som lister, billeder, tabeller, indholdsfortegnelse osv. Derefter indlæste jeg OOXML dokumentet i LibreOffice og ODF dokumentet i MS-Office. Der var færre fejl i MS-Office/ODF kombinationen end i LibreOffice/OOXML kombinationen.

Dette kan fortolkes på flere måder, bl.a.

  • Microsoft har geni-programmører til implementere ODF-import funktionen i MS-Office og LibreOffice har klaphatte til at implementere OOXML-importen i LibreOffice.
  • ODF formatet er nemmere og mere overskueligt at implementere end OOXML

Efter også at have studeret en mindre række tilfældige prøver af hhv. OOXML og ODF XML dokument-teksten hælder jeg mod udfald nr. 2: ODF synes for mig at være det mest overskuelige og tilgængelige format. Jeg medgir, at valget er foretaget på et meget lille og snævert grundlag.

31. juli 2014 kl. 11:26
ODF 1.2 i ISO (PAS submission)

Jesper, som formand for udvalget i Dansk Standard for OOXML/ODF burde du kende forskellen på formater og standarder

(Med en lettere humoristisk tilgang)

  • Et format: En programmør/producent/interessent synes der er brug for at persistere en tilstand/funktionalitet i et program; sætter sig ned og skriver en serialiserings rutine og vupti: et nyt format er opfundet.
  • En standard: En standardkommité modtager et eksisterende eller opfinder et nyt format; dette splittes til atomer og bekrives i minutiøse detaljer; hver del undersøges grundigt, testcases beskrives og udfærdiges; der indhentes høringssvar fra en million interessenter, inklusive modstandere af standarden; ændringsforslag indkorporeres i standarden. Processen gentages i forskellige nationale kommmitéer, der sørger for at ÆØÅ fungerer osv osv. Efter et par år eller 4 med denne process og andre skænderier foreligger den nye standard.

Det er derfor, der findes rigtig mange formater og forholdsvis få standarder.

Mht. 1 standard versus 2 standarder til løsning af samme opgave:

Jeg gentager: Med 2 standarder fordobler du arbejdet hos forbrugerne af standarderne. Og som du påstår: Når standarderne også er indbyrdes inkompatible, således du i mange tilfælde overhovedet ikke kan konvertere fra det ene til det andet format og vice-versa er situationen helt håbløs. I dit oprindelige blogindlæg argumenterer du jo selv - via et retorisk spørgsmål - for at fjerne ODF og derved kun have et standard-format, OOXML, til udveksling. Så er vi jo enige om kun at have eet format - Vi er blot uenige om hvilket format, der skal benyttes.

Mht. valg af standard format: Du kritiserer mit umiddelbare personlige valg af dokumentstandard. Du har selvfølgelig ret: Hvis det var mit job og ansvar at foretage et valg mellem forskellige dokumentformater ville jeg sætte mig meget dybere ind i de tekniske specifikationer. Det er det, jeg forventer du ville gøre. Det er det, jeg forventer at de ansvarlige for det engelske valg af standardformat har gjort. I er øjensynligvis uenige.

Du argumenterer for kun at benytte OOXML, fordi ODF har gjort sit job "at presse Microsoft til at underlægge dokumentformatet for Microsoft Office til international standardisering". De ansvarlige i England har gjort et andet valg.

Mht. Sammenhæng mellem funktionalitet i MS-Office og OOXML standarden. Du har ret i, at der er stort set er 100 % overensstemmelse mellem MS-Office og OOXML dokumentformatet - "topologisk sammenhæng". Er det det man ønsker i et udvekslings format ?

For nu at sige det som det er:

  • Hvis man kun vælger OOXML som udvekslingsformat forbliver Danmark et "Microsoft" land for tid og evighed og MS-Office vil kun sporadisk blive udkiftet med andre office produkter.
  • Hvis man kun vælger ODF har de øvrige producenter en større chance for komme ind på markedet. Og Microsoft tvinges til bedre support af ODF. Det er det valg, som englænderne har truffet.
  • Hvis man benytter begge formater til udveksling vil der altid være bøvl, hvis man modtager data i et format, som er dårligt understøttet af sit office system. Med Microsofts dominerende markedsandel medfører det et de-facto valg a "kun OOXML" med de føromtalte konsekvenser.

Mht. din ad-hominem argumentation om andre personer og deres valg, f.eks "tåberne i England" : Et godt råd: Gå efter bolden og ikke manden. Det vil du til enhver tid komme længere med.

29. juli 2014 kl. 13:00
ODF 1.2 i ISO (PAS submission)

Hvad baserer du din vurdering af, at problemet er 'ganske minimalt' på?

Jeg har været selvstændig it-konsulent i 30 år, hvor kundekredsen for det meste har været offentlige institutioner som ministerier, styrelser, regioner, amter og kommuner. En ikke uvæsentlig del af den tid er gået med at implementere løsninger i de forskellige office miljøer.

Det er helt korrekt - problemet løses ved at anvende åbne standarder. Men det konkrete problem løses på ingen måde ved kun at acceptere én åben standard. Problemet havde været næsten lige så stort, hvis man havde valgt udelukkende at acceptere OOXML.

At implementere 2 standarder, som har meget store overlap, til at løse 1 problem er ikke hensigtsmæssigt. Som minimum fordobler du arbejdet med implementeringen. Og du indfører ekstra problemer, når du internt skal transformere data mellem de to formater.

Ja, det klarer så dataproblematikken, men hvad med funktionalitetsproblematikken? Du kan ikke ignorere dette - specielt ikke, når vi snakker om dokumentformater, hvor "funktionalitet" og "data" går hånd i hånd.

Det er et minimalt antal gange, hvor jeg har oplevet at det var nødvendigt at eksportere/importere office dokumenter med funktionalitet som ikke er understøttet af både ODF og OOXML. Den eneste gang, som jeg pt. husker, var i forbindelse med et "Godzilla-Frankenstein" regneark, som implementerede et helt sagbehandlersystem i Excel. Dette gav i øvrigt så mange andre og voldsomme problemer, så løsningen var at reimplementere regnearket som et regulært databasesystem.

Jeg vil ikke blande mig i hvilket officeprodukt, som internt benyttes i en given virksomhed. Dette valg beror på en lang række forskellige kriterier, nogle rationelle, andre mindre rationelle. Så længe et dokument "flyttes rundt" internt i en virksomhed kan man benytte det format, som supporteres bedst af det valgte office produkt.

Men i det øjeblik, hvor dokumentet flyttes ud af virksomheden eller arkiveres, må man "begrænse" fuktionaliteten i dokumentet til hvad det valgte udvekslingsformat understøtter. Om det så er ODF eller OOXML er basalt set ligegyldigt - så længe det er et format. Men det er klart, at valget af standardformat helt givet også vil influere på valget af office produkt. Mit personlige valg ville være ODF som jeg mener dækker kravene for dataudveksling og er et mere overskueligt format end OOXML. Jeg er sikker på, at du også har dit yndlingsformat ;-)

28. juli 2014 kl. 10:37
ODF 1.2 i ISO (PAS submission)

Og hvad foreslår du så, at programmer som Microsoft Office, Apple iWorks eller andre gør ved deres funktionaliteter, der ikke kan persisteres i ODF?</p>
<p>Mener du virkeligt og ædrueligt, at et valg af kun ét muligt format løser dette problem?

Det er et problem, du vil altid vil have - uanset om valget hedder ODF, OOXML eller noget helt tredje. Der vil aldrig være et 100% overlap mellem alle mulige "dokumentbehandlende" progammers funktionaliteter og standardformatets mulighed for at persistere disse.

Den eneste mulighed for at opnå 100% kompatibilitet er ved at vælge et program i en bestemt version og et format, som så er det valgte programs "native" format. Og det er vel præcis den situation, som man ønsker at komme væk fra.

Så svaret på dit spørgsmål er: Nej, det løser ikke det - i min optik ganske minimale - problem, men det løser et andet, væsentligt større problem: At kunne udveksle data mellem programmer fra forskellige leverandører.

25. juli 2014 kl. 16:12