Svaret på krig om dokumentformater er politisk

ANALYSE: Partier og parter skændes om, hvilket dokumentformat det offentlige Danmark skal satse på i fremtiden. Under diskussionen ligger et mere grundlæggende spørgsmål, der handler om open eller closed source.

Diskussionen om, hvilket dokumentformat det offentlige Danmark skal vælge som sit foretrukne, bølger for øjeblikket frem og tilbage i folketingssalen. Slaget står mellem OOXML, som er standard i Microsofts kontorpakke Office, eller ODF-standarden, der bliver brugt i open source-kontorpakken Openoffice.org og i de kontorpakker, der bygger på den. Lige nu forsøger politikerne ikke alene at finde ud af, om Danmark skal satse på den ene eller begge standarder, men også hvilken udgave af de enkelte standarder, der i så fald skal satses på.

For at gøre det i forvejen meget komplekse spørgsmål endnu mere kompliceret, er der nemlig flere varianter af både ODF og OOXML, som udover at være mere eller mindre standardiserede også har forskellig funktionalitet og fremtidsperspektiv.

Den igangværende debat har sit udspring helt tilbage i sommeren 2006, hvor Folketinget vedtog beslutningsforslag B103, der har pålagt det offentlige Danmark at bruge åbne standarder i forskellige henseender. Efterfølgende blev det besluttet, at standarderne for dokumenter skulle være OOXML og ODF i en prøveperiode, og det har siden 1. januar 2008 betydet, at det offentlige skal kunne modtage begge dokumentformater. Samtidigt skal alle nye it-systemer som udgangspunkt understøtte et af de to formater.

Spørgsmålet om dokumentformater handler dog om meget mere, end hvorvidt et dokument skal hedde .doc, .odt, .docx eller noget helt fjerde, når der bliver trykket på gemknappen i et tekstbehandlingsprogram. I en rapport fra Konkurrencestyrelsen skønnes det, at Microsoft sidder på mindst 90 procent af det danske marked for kontorpakker, og det er blandt andet den konkurrencesituation - eller mangel på samme - politikerne med B103 forsøger at gøre noget ved.

Åbne standarder betyder i princippet, at det er muligt for alle og enhver at lave eksempelvis et tekstbehandlingsprogram, der anvender standarderne. Indtil videre har de facto standarden for dokumentformater i det offentlige (og andre steder) været Microsofts lukkede format, der omfatter .doc-filtypen i Word. Det vil sige, at kommuner, regioner osv. som udgangspunkt anskaffer sig en kontorpakke fra Microsoft, hvis de vil være nogenlunde sikre på gnidningsløst at kunne udveksle redigerbare dokumenter med hinanden og resten af Danmark.

Effekten er selvforstærkende, fordi de øvrige softwareleverandører til det offentlige bygger deres løsninger op, så de integrerer med Microsofts kontorpakke. Den konkurrencesituation skulle B103 altså lave om på. Beslutningsforslaget, der på papiret tvinger det offentlige væk fra en standard, som tilhører en enkelt leverandør, har imidlertid vist sig at være særdeles vanskeligt at implementere i praksis.

Et politisk nedsat ekspertudvalg, der ellers skulle hjælpe politikerne med at træffe en beslutning, nåede frem til, at det var for tidligt at sige noget konkret i forhold til de endnu ikke særligt udbredte formater. Og Konkurrencestyrelsen meldte i august 2009 ud, at det foreløbigt vil være bedst, hvis offentlige it-systemer kan behandle dokumenter i enten det ene eller det andet format, og at systemerne kan modtage dokumenter i begge formater.

Konkurrencestyrelsen lægger blandt andet til grund for udmeldingen, at et valg af OOXML på kort sigt vil betyde, at kun Microsoft vil kunne levere varen, mens et rent ODF-valg ikke sikrer pålidelig dokumentudveksling mellem forskellige kontorpakker.

Udover udsagn fra ekspertudvalget og styrelsen har politikerne kunnet bevidne en benhård mediekrig mellem Microsoft og ODF-tilhængere. Microsoft beskylder blandt andet ODF for at være utilstrækkeligt og ODF-tilhængerne hævder, at det i praksis er umuligt for andre end Microsoft at implementere OOXML, fordi standarden er alt for omfattende.

Nu er beslutningen om dokumentformater, der ellers skulle været truffet omkring 1. juli, og som i første omgang blev udskudt til 1. november, blevet yderligere udskudt. Mens politikerne forsøger at træffe et kvalificeret valg, så fortsætter den teknologiske udvikling uden skelen til, hvad regeringen eller en eventuelt samlet opposition finder ud af.

Eksempelvis er PDF-formatet, siden diskussionen begyndte i 2006, blevet standardiseret i ISO, hvilket har fået ekspertudvalget til at foreslå, at PDF bliver brugt som udvekslingsstandard for alle ikke-redigerbare dokumenter i det offentlige og mellem det offentlige og virksomheder og borgere. Den løsning sikrer en gnidningsløs udveksling af de fleste dokumenter, da langt størstedelen af den borger- og virksomhedsrettede kommunikation slet ikke skal kunne redigeres af modtageren.

Desuden indeholder både Openoffice.org og Microsofts Office 2007 nu mulighed for at gemme dokumenter i PDF.

Men i sidste ende er det formentlig ikke en til tider pedantisk diskussion om, hvorvidt OOXML eller ODF er bedst, der alene er årsagen til, at ethvert it-site med respekt for sig selv trækker mindst ti debatindlæg fra engagerede it-entusiaster, når en artikel handler om dokumentformater. Den virkelige kerne i debatten præges af en ældgammel ideologisk diskussion om open source eller closed source - sidstnævnte ofte repræsenteret ved Microsoft. Og diskussionen handler i høj grad også om økonomi, fordi open source-kontorpakken som udgangspunkt er gratis. Det diskuteres dog heftigt, om en licens-besparelse bliver ædt op af omskoling og uddannelse af brugere, vedligeholdelse, implementering etc.

Under alle omstændigheder, så vil politikernes valg, hvis det ender med at falde ud i ODF-tilhængernes favør, ikke alene være et hårdt slag mod Microsofts historisk forankrede markedsdominans, men også være et skulderklap til open source-baserede produkter som Openoffice.org, mens en løsning, der favoriserer begge formater eller den OOXML-udgave, Microsoft foretrækker, vil være ensbetydende med status quo og dermed en (midlertidig) fredning af Microsoft, der som bekendt sidder på langt størstedelen af markedet.

I hvert fald tyder alt på, at det er nødvendigt med en politisk afgørelse, hvis der skal afklaring på formatkrigen.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (171)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Ove Larsen

Analysen overser helt en af de grundlæggende debatter i spørgsmålet om Åbne Standarder i den offentlige administration.

Spørgsmålet har hele tiden været - om det offentlige - i al fremtid skal være leverandør-afhængig.

Andre landes offentlige myndigheder kan godt finde ud af - at gøre sig fri af leverandør bindinger - og indføre Åbne Standarder for dokument udveksling - for at sikre borgernes data i fremtiden ikke skal være afhængige af en bestemt leverandør of software.

Det handler blandt andet om samfundets bedste - ikke en enkelt leverandørs bedste - og ikke som denne analyse forsøger - at forfladige debatten og gøre det til en kamp mellem forskellige produkter.

  • 0
  • 0
#2 Anonym

om en licens-besparelse bliver ædt op af omskoling og uddannelse af brugere, vedligeholdelse, implementering etc.

Under alle omstændigheder, så vil politikernes valg, hvis det ender med at falde ud i ODF-tilhængernes favør, ikke alene være et hårdt slag mod Microsofts historisk forankrede markedsdominans

Hvis det ikke er begrundelse nok, så skal jeg love for at sagen er politisk, grænsende til mystisk, med mulighed for masser af konspirationsteorier !

  • 0
  • 0
#3 Deleted User

Jeg er helt enig. Valget af dokumentstandard er (også) et principielt valg imellem to vidt forskellige principper for, hvordan software i det hele taget skal anvendes i den offentlige administration. Ligesom det er et principielt valg af, om man for nemheds skyld vil lade en leverandør bestemme, hvordan forvaltningerne skal agere (og kunne agere), eller om man vil fastholde den demokratiske valgfrihed. Det er en af årsagerne til, at der er så meget diskussion omkring det.

  • 0
  • 0
#4 Peter Favrholdt

Fra artiklen:

eller ODF-standarden, der bliver brugt i open source-kontorpakken Openoffice.org og i de kontorpakker, der bygger på den.

Der er også kontorpakker der ikke "bygger på OpenOffice" som implementerer ODF, f.eks. koffice og google docs. Men det er rigtigt at OpenOffice af mange betragtes som reference-implementationen.

  • 0
  • 0
#6 Jens Christian Damgaard

mens et rent ODF-valg ikke sikrer pålidelig dokumentudveksling mellem forskellige kontorpakker.

Denne konklusion stammer fra 2007, hvor der sidst blev lavet grundig undersøgelse af interoperabiliteten mellem de mest gængse kontorpakker - med et sørgeligt resultat for alt andet end doc. I 2009 ser verden meget anderledes ud på det punkt: ODF KAN sikre pålidelig dokumentudveksling mellem forskellige kontorpakker (f.eks. de to mest udbredte OpenOffice og MS Office 2003)

Der har desværre ikke været interesse fra ITST eller andre i at lave en ny test af interoperabilitet anno 2009. Hvorfor mon?

  • 0
  • 0
#7 Stig Libori

Hej Jesper

Nu kunne jeg aldrig drømme om at bruge google docs - i min verden bliver der arbejdet med dokumenter på den enkelte maskine og ikke i "skyen" - i hvert fald, hvis dokumenterne er bare lidt vigtige.

Men koffice -sammenligningen synes jeg ikke er fair, eftersom koffice ikke er færdigudviklet - og eksempelvis stadig er meget mangelfuld når det eksempelvis gælder tabeller og kommentarer.

Mere interessant synes jeg det er, at de dele af koffice der faktisk er færdigudviklede arbejder fremragende sammen med openoffice - det tyder på, at det reelt er den samme dokumentstandard der ligger bag. Og det må vel være det interessante - ikke om koffice er færdigudviklet eller ej!

  • 0
  • 0
#8 Jesper Lund Stocholm Blogger

Hej Stig,

Men koffice -sammenligningen synes jeg ikke er fair

Jeg sammenligner sådan set ikke KOffice med OOo - det ville heller ikke i mine øjne være fair. Jeg stiller blot spørgsmålstegn ved, om KOffice kan regnes som en "implementering af ODF".

Det pudsige er jo (eller, "hykleriske"), at jeg ofte ser udsagn som "ODF er jo implementeret i masser af programmer herunder i OOo, Google Docs, KOffice, AbiWord etc". Dette stiller ingen spørgsmålstegn ved.

Men i det øjeblik jeg siger "OOXML er jo implementeret i masser af programmer, herunder Microsoft Office 2003, 2007, 2008, iWork, WordPerfect, Novell OO, NeoOffice, Microsoft Web Office etc", så kan du være stensikker på, at der er nogen, der vil svare: "er de programmer du nævner fulde implementeringer af OOXML?"

Så i forhold til tilstedeværelse af en bred vifte af programmer på markedet, der implementerer en givet standard, så er det da super relevant, om programmerne rent faktisk kan bruges til noget - eller blot er "i seneste beta". Hvis man i fx Region Midtjylland skal bruge en kontorpakke til brug i hele regionen, så nytter det jo ikke noget at bruge KOffice og så affærdige folks klager over den med, at "den er jo ikke færdigudviklet".

  • 0
  • 0
#9 Jesper Lund Stocholm Blogger

Hej Jens Christian,

I 2009 ser verden meget anderledes ud på det punkt: ODF KAN sikre pålidelig dokumentudveksling mellem forskellige kontorpakker (f.eks. de to mest udbredte OpenOffice og MS Office 2003)

Er dine erfaringer på baggrund på kontorpakker (eller plugins) på en bred vifte af kodebaser, eller er dine erfaringer udelukkende baseret på software fra Sun/ORACLE?

  • 0
  • 0
#10 Stig Libori

Jeg er enig med dig i, at for den professionelle bruger er der kun to reelle implementeringer af odf (Sun's version, Novell's version). Og samarbejdet mellem de to er så stort, at man kan stille spørgsmålstegn ved, om det er en eller to implementeringer?

Men så let er det altså ikke at afskrive Koffice, eftersom det indenfor det næste års tid vil blive en fuldt implementeret version af odf (og uafhængig af Sun's implementering). Så det er i horisonten - medens ingen andre end MS vil kunne udvikle en fuld version af ooxml over en meget lang tidshorisont (ja, selv MS klager jo over, at de ikke ved om de nogensinde får udviklet en fuld version af ooxml strict).

Man kan blokere for konkurrence på mange måder, og Microsoft har med ooxml valgt at gøre det ved at gøre det uoverkommeligt at implementere standarden for ale andre end Microsoft. Lidt som når Japan for nogle år siden havde fri import af en masse produkter - men først skulle de lige skilles ad og samles igen for at se om de overholdt reglerne, hvilket gjorde produkterne ikke-konkurrencedygtige.

  • 0
  • 0
#11 Jens Christian Damgaard

Jesper

Er dine erfaringer på baggrund på kontorpakker (eller plugins) på en bred vifte af kodebaser, eller er dine erfaringer udelukkende baseret på software fra Sun/ORACLE?

I Region Midtjylland anvender vi "kun" to forskellige kontorpakker: MS Office 2003 og OpenOffice.org. Disse er samtidig de mest udbredte og er derfor et godt sted at starte. Der er installeret plugin på MS Office 2003, men for brugerne er det bare en del af kontorpakken. Det vigtigste er at ODF virker på tværs af begge.

Det er mange år siden vi forlod WordPerfect, så derfor er det ikke relevant for os at teste den, ligesom vi heller ikke har interesse i KOffice o.a.

Og netop derfor efterlyser jeg en mere grundig test af situationen i dag.

Hvad blev der forresten af din test af OOXML-interoperabilitet?

  • 0
  • 0
#12 Jesper Lund Stocholm Blogger

Hej Stig,

selv MS klager jo over, at de ikke ved om de nogensinde får udviklet en fuld version af ooxml strict

Der er ingen tvivl om, at Microsoft naturligvis kan implementere S til fx Office 2010++. Når de slår sig så meget i tøjret, så er det naturligvis, at de med S bliver nødt til at lægge den fulde kompatibilitet med "fortiden" bag sig. Det prøvede de jo med skiftet fra dokumentformatet i Office 95 til Office 97, og hvis man taler med en Microsoft-mand, der var der dengang, så får de stadig ticks omkring øjnene, når de genlever ramaskriget fra deres kunder :-)

selv MS klager jo over, at de ikke ved om de nogensinde får udviklet en fuld version af ooxml strict

OOXML er jo reelt en XML-udgave af de binære dokumentformater, og disse har alle andre kontorpakker jo haft understøttelse for i årevis. Derfor må du gerne konkretisere, hvorfor det pludseligt skulle gøre det uoverkommeligt, at dokumentformatet nu ikke er binært men XML-baseret og i øvrigt fuldt specificeret. Ja, man kan jo endda genbruge den interne objektmodel man allerede har til de binære dokumenter.

  • 0
  • 0
#13 Jesper Lund Stocholm Blogger

Hej Jens Christian,

Det vigtigste er at ODF virker på tværs af begge.

Ja - men det du siger er jo, at for RM virker ODF på tværs af [b]Suns OOo[/b] og [b]Suns plugin[/b] til Microsoft Office 2003.

Microsoft Office 2003 har jo ikke i sig selv understøttelse for ODF.

Hvad blev der forresten af din test af OOXML-interoperabilitet?

Den er på vej :o). Mit problem har været, at da I i Region Midtjylland ikke har accepteret, at jeg offentliggør jeres skabeloner som en del af dokumentationen for testen, så er det blevet noget mere kompleks for mig.

Den hurtige konklusion (og jeg har ikke færdiggjort hele testen endnu) er, at OOXML-skabelonen åbnes fejlfrit i

Microsoft Office 2007 iWork '09 Corel WordPerfect 14

I programmer som Lotus Symphony, OOo og AbiWord er skabelonen ubrugelig.

  • 0
  • 0
#14 Jens Christian Damgaard

Microsoft Office 2003 har jo ikke i sig selv understøttelse for ODF.

MS Office 2003 har heller ikke i sig selv understøttelse af PDF, men der produceres masser af PDF'er hver dag fra MS Office + PDF-tilføjelse. Igen er det anvendeligheden i praksis der har betydning.

Den er på vej :o). Mit problem har været, at da I i Region Midtjylland ikke har accepteret, at jeg offentliggør jeres skabeloner som en del af dokumentationen for testen, så er det blevet noget mere kompleks for mig.

Vi har stadig ingen skabeloner i OOXML-format. Jeg gav dig et anonymiseret docx-testdokument som vi selv har brugt. Det må du stadig gerne bruge (og publicere) http://dump.no/files/3fe24ed34c1a/ooxml-test.docx

  • 0
  • 0
#17 Jesper Lund Stocholm Blogger

Hej Jon,

Mon ikke at den gav et forkert resultat?

Faktisk gav testen præcist det resultat jeg forventede - nemlig, at der er alternativer til Microsoft Office, der kan åbne skabelonen fra RM.

Så jeg har ikke som sådan nogen værdi ikke at få skrevet artiklen færdig.

(men måske skulle jeg blot de næste dage droppe diskussionerne herinde og fokusere på artiklen)

:o)

  • 0
  • 0
#18 Jesper Lund Stocholm Blogger

Hej Anders,

Så dokumentet åbner perfekt i Microsoft Office 2003. Er det ikke nok for slutbrugeren?

Skægt - jeg troede egentlig, at hele idéen med at anvende åbne standarder var at sikre et frit valg - og ikke være tvunget til at vælge software fra én leverandør - uanset om navnet er Microsoft eller Sun/ORACLE.

Men jeg må dermed også antage, at siden slutbrugerens oplevelse ultimativt er det vigtigste, så kan vi vel blot blive ved med at bruge Microsoft Office og OOXML?

;o)

  • 0
  • 0
#19 Anders Rosendal

Skægt - jeg troede egentlig, at hele idéen med at anvende åbne standarder var at sikre et frit valg - og ikke være tvunget til at vælge software fra én leverandør - uanset om navnet er Microsoft eller Sun/ORACLE.

Wow.

Nej du skal være velkommen til at bruge et ms produkt der kan læse ODF. Hele pointen er åbenbart gået fuldstændig hen over hovedet på dig. Det står ms frit for at implementere ODF - evt. bare tage det Open Source kode der er og bruge det. Derimod står det ikke OOo frit for bare at gøre det samme med docx.

Det forbavser mig at du ikke har sat dig mere ind i sagen!!

Det virker som om din pointe er: At så længe ms nægter at understøtte en open standard(ODF) må andre ikke vælge denne standard. Det er jo fuldstændigt tåbeligt at skrive sådan noget Jesper. Jeg forstår du pga. professionelle interesser gerne vil have ooxml-t igennem, men kan du ikke bruge lidt bedre argumenter?

Og nej. At have et monopol på dokument-området vil IKKE gavne brugeren (i det lange løb). Du er selvfølgelig velkommen til at være uenig.

  • 0
  • 0
#20 Jesper Lund Stocholm Blogger

Hej Anders,

Det står ms frit for at implementere ODF - evt. bare tage det Open Source kode der er og bruge det. Derimod står det ikke OOo frit for bare at gøre det samme med docx.

Hvorfor gør det ikke det? Når Apple, Corel og Novell kan - så kan Sun/ORACLE vel også?

Det forbavser mig at du ikke har sat dig mere ind i sagen!!

Jamen, gør mig gerne klogere :o)

Det virker som om din pointe er: At så længe ms nægter at understøtte en open standard(ODF) må andre ikke vælge denne standard.

Jeg har aldrig, aldrig, aldrig nogensinde argumenteret for, at OOXML (i en eller anden variant) skulle vælges som eneste dokumentformat.

Jeg forstår du pga. professionelle interesser gerne vil have ooxml-t igennem, men kan du ikke bruge lidt bedre argumenter?

Jeg ønsker ikke at anbefale kun "OOXML-T" - det ville i mine øjne være lidt for tilbageskuende. Jeg anbefaler, at man anbefaler "hele OOXML".

Derudover virker det lidt som om, at det pludseligt er blevet meget interessant at anklage mig for at have en "monetær agenda" (eller rettere, er korrupt). Men jeg (og CIBER) har ingen økonomisk interesse i enten det ene eller det andet valg. Vi er tudende ligeglade med, om vores kunder ønsker at understøtte OOXML eller ODF - vi giver dem blot, hvad de ønsker. Personligt har jeg også bidraget til Suns OSS-implementering af .Net-biblioteket til ODF-filer (selvom jeg er pissed over at skulle dele min ophavsret med Sun, men det er en helt anden historie). Jeg bidrager også til generel forbedring af ODF via indsendelse af kommentarer og forslag til forbedringer til ODF TC samt via Dansk Standard (hvilket jo er enormt mere end fx OSL, der jo ellers "lever og ånder for ODF" - men de er åbenbart af den opfattelse, at "ingen er blevet fyret/kritiseret for at anvende ODF" - uanset kvaliteten af denne).

Men det er åbenbart mere opportunt at angribe min person end at forholde sig til mine argumenter.

  • 0
  • 0
#21 Anders Rosendal

Jeg ønsker ikke at anbefale kun "OOXML-T" - det ville i mine øjne være lidt for tilbageskuende. Jeg anbefaler, at man anbefaler "hele OOXML".

ooxml-s findes ikke endnu og måske når ms at implementere det i 2017. Måske senere. Måske aldrig. Hvem ved?

Så du anbefaler ooxml-t og noget som ikke findes.

Hvad er problemet med at implementere ODF i ms-office pakken?

Findes der en Open Source implementation af docx fra ms som Sun kan bruge?

  • 0
  • 0
#22 Jesper Lund Stocholm Blogger

Hej Anders,

Så du anbefaler ooxml-t og noget som ikke findes.

Jeg anbefaler OOXML, der indeholder både OOXML-T samt en vej til OOXML-S. Hvis jeg kun anbefalede OOXML-T, så var der ikke en vej til S.

Hvad er problemet med at implementere ODF i ms-office pakken?

At ODF ikke kan beskrive al funktionalitet i Microsoft Office. Du satte før selv slutbrugerne i højsædet, så skulle vi ikke forsøge at finde en løsning, der ikke giver for meget bøvl for dem?

Findes der en Open Source implementation af docx fra ms som Sun kan bruge?

Næeh, men det har jo ikke afholdt Apple, Corel og Novell, så jeg spørger igen:

"Når Apple, Corel og Novell kan - så kan Sun/ORACLE vel også?"

Det var jo Sun, der har været primus-motor bag reverse-engineering af DOC-formatet, så de har bestemt kompetencerne til det - skulle man mene.

  • 0
  • 0
#24 Anders Rosendal

At ODF ikke kan beskrive al funktionalitet i Microsoft Office.

Det burde jo ikke forhindre dem i at LÆSE dem! Det lykkedes på forunderlig vis Sun at implementere et plugin som gør det! Jeg tror vi begge er klar over at ms ikke ønsker at røre ved ODF fordi de tjener mange penge på at office kun virker med office - aka. monopol.

Igen: Jeg kan med ms office åbne ODF dokumenter. Jeg kan ikke åbne docx i OOo. Så ODF er bredere understøttet end docx.

Det var jo Sun, der har været primus-motor bag reverse-engineering af DOC-formatet, så de har bestemt kompetencerne til det - skulle man mene.

At du kan mene at vi I danmark skal vælge en "standard" som basererer sig på at staten er nødt til at sætte sin lid til "reverse-engineering" siger jo alt.

Tsk tsk.

  • 0
  • 0
#25 Jesper Mørch

[quote]Findes der en Open Source implementation af docx fra ms som Sun kan bruge?

Næeh, men det har jo ikke afholdt Apple, Corel og Novell, så jeg spørger igen:

"Når Apple, Corel og Novell kan - så kan Sun/ORACLE vel også?"[/quote]

Jesper, nu må du holde op med det ævl! Hvordan vil du implementere lukket kode i et opensource-produkt uden at overtræde copyright?

Hvis du kan det, tror jeg du er sikret en lysende fremtid i FOSS-branchen. Reverse-engineering er en ting, implementation af eksisterende kopibeskyttet kode er noget andet. Apple, Corel og Novell sælger jo netop IKKE opensource-versioner af deres office-applikationer.

I øvrigt var kOffice så vidt jeg husker de første til at implementere ODF som native format tilbage omkring 2000. At koffice så benytter en frames-baseret dokument-konstruktion der principielt minder mere om super-avanceret HTML er noget andet. I øvrigt tror jeg også der udvikles mere på OOo end på kOffice. Til gengæld indeholder kOffice nogle ret gennemførte værktøjer til bl.a. diagram-tegninger m.m.

Historien har vist at MS kun meget modvilligt åbner så meget op for tingene at der kan komme reel konkurrence. Sandsynligheden for at de ser nogen som helst interesse i at skifte fra OOXML-t til OOXML-s er som jeg ser det, derfor temmelig begrænset.

Som det er blevet nævnt før, blev MS tilbudt at gå med i ODF-samarbejdet, men ville hellere fortsætte de binære formater. Nu hvor resten af verden så har fået øjnene op for XML, er MS' binære formater så blevet sovset ind i XML. Jeg mindes MS' holdning til internettet i midt-halvfemserne, og har nu hørt at MS har været nødt til at implementere en "kompatibilitets-tilstand", for at kunne vise de sider som blev udviklet specifikt til MSHTML.

Du kan selvfølgelig tro og synes hvad du vil, men historien er slem til at gentage sig selv... Selv Sokrates kunne konkludere det for flere tusind år siden, og jeg tvivler på at det vil forandres mærkbart...

  • 0
  • 0
#26 Henrik Jensen

Jesper, nu må du holde op med det ævl! Hvordan vil du implementere lukket kode i et opensource-produkt uden at overtræde copyright?

Hvor kom den lukkede kode ind i billedet?

Apple, Corel, Novell m.v. har da ikke kopieret kode fra MS Office så vidt jeg ved. De har læst en standard og så implementeret den.

I øvrigt var kOffice så vidt jeg husker de første til at implementere ODF som native format tilbage omkring 2000.

Du mener vel XML og ikke ODF?

Som det er blevet nævnt før, blev MS tilbudt at gå med i ODF-samarbejdet, men ville hellere fortsætte de binære formater. Nu hvor resten af verden så har fået øjnene op for XML, er MS' binære formater så blevet sovset ind i XML.

Det lyder som om at brug af XML er noget nyt for Microsoft.

Microsoft havde allerede XML formater til Word + Excel i beta version af Microsoft Office 2003 før at OpenOffice.org XML blev sendt til OASIS. Frigivelse af MS Office 2003 med XML formater var i april 2003, ca. 2 år for at ODF blev godkendt i OASIS.

  • 0
  • 0
#27 Jesper Lund Stocholm Blogger

Hej Anders,

Det burde jo ikke forhindre dem i at LÆSE dem! Det lykkedes på forunderlig vis Sun at implementere et plugin som gør det!

Du laver en fejl, hvis du tror, at Suns plugin til Microsoft Office er en fuld implementering af ODF. Den er lige så fejlbehæftet som ODF-implementeringen i Microsoft Office 2007. Henrik Jensen har tidligere gået Jens Christian på klingen omkring nogle af de ting, som han ikke kunne få til at virke, men Jens Christian klappede desværre i som en østers.

ODF er bredere understøttet end docx.

Ja, jeg har aldrig sagt andet - det var også den konklusion Konkurrencestyrelsen kom frem til, og jeg er helt enig. Jeg er faktisk sikker på, at også Microsoft etellerandet sted har anerkendt det.

At du kan mene at vi I danmark skal vælge en "standard" som basererer sig på at staten er nødt til at sætte sin lid til "reverse-engineering" siger jo alt.

Joeh, men jeg har nu aldrig anbefalet en godkendelse af DOC-formatet, og jeg er ikke vidende om funktionalitet i OOXML, der kræver reverse-engineering af Microsoft Office. Det er muligt, at du har viden om dette, så den må du gerne dele med os. Men det er da klart, at jeg vil tro, at resourcerne ved Sun, der lavede reverse engineering af DOC-formatet nok kunne bruges til deres OOXML-implementering.

... men når man som du læser mine indlæg som fanden læser biblen, så er det jo lissom skrevet i kortene, at der vil opstå misforståelser imellem os.

:o)

  • 0
  • 0
#28 Jesper Lund Stocholm Blogger

Hej Henrik,

Apple, Corel, Novell m.v. har da ikke kopieret kode fra MS Office så vidt jeg ved. De har læst en standard og så implementeret den.

Jeps - og jeg ved positivt fra samtaler med både udviklere på Microsoft Office og Mac OSX, at der har været uhyggeligt lidt kontakt imellem disse teams under udviklingen af OOXML-understøttelsen i Mac OSX og iWork. Apple startede jo med OOXML-implementering umiddelbart efter overgivelse af OOXML til ECMA, og når de trods alt engang imellem spurgte om fortolkning af elementer og attributter i TC-45 i ECMA, så kunne de andre deltagere ikke få noget som helst at vide om den konkrete brug.

Mac OSXs implementering af OOXML er i høj grad "by the book" og reelt ikke andet.

  • 0
  • 0
#29 Stig Libori

Hej Jesper

Du skriver:

"OOXML er jo reelt en XML-udgave af de binære dokumentformater, og disse har alle andre kontorpakker jo haft understøttelse for i årevis. Derfor må du gerne konkretisere, hvorfor det pludseligt skulle gøre det uoverkommeligt, at dokumentformatet nu ikke er binært men XML-baseret og i øvrigt fuldt specificeret. Ja, man kan jo endda genbruge den interne objektmodel man allerede har til de binære dokumenter."

Jeg må indrømme, at den havde jeg ikke set komme! For mig bekendt er understøttelsen af de binære formater i Microsofts kontorpakker ikke overbevisende i andre selskabers kontorpakker. Det har jo netop været et af kritikpunkterne: at man mister information ved at skifte til en anden kontorpakke!

Forskellen på ooxml strict og de tidligere binære formater er vel, at før ooxml var det med sikkerhed umuligt for andre kontorpakker at opnå fuld dokumentunderstøttelse af Microsofts binære formater - men ooxml strict er der en teoretisk mulighed for det - den synes blot uoverkommelig. Microsoft selv siger jo, at de tidligst (!) kan have deres egen version klar i år 2015 - på trods af, at de allerede har udtænkt formatet, og har de klart største ressourcer at kaste efter projektet.

Det svarer lidt til at invitere sin fattige ven til et slag golf i rigmandsgolfklubben: invitationen er irrelevant, for han har ganske enkelt ikke pengene til at blive medlem af klubben!

  • 0
  • 0
#30 Jesper Lund Stocholm Blogger

Hej Stig,

For mig bekendt er understøttelsen af de binære formater i Microsofts kontorpakker ikke overbevisende i andre selskabers kontorpakker

Jeg ved ikke lige, hvor du har været henne, men jeg hører jævnligt folk håne Microsoft over, at OOo er bedre til at håndtere DOC-filer end Microsoft Office. Jeg har faktisk selv brugt OOo til at åbne en DOC-fil som Microsoft SharePoint og Office havde ødelagt. Ja, selv ITSTs pilotprojekter havde kun en enkelt fast og overbevisende konklusion - nemlig at hvis man udelukkende ønskede god interop, så var det bedste valg DOC og hverken ODF eller OOXML.

Det du tænker på er sikkert, hvis man ønsker at benytte fx OOo samt ODF, hvor man jo vil opleve problemer.

Forskellen på ooxml strict og de tidligere binære formater er vel, at før ooxml var det med sikkerhed umuligt for andre kontorpakker at opnå fuld dokumentunderstøttelse af Microsofts binære formater

Det er korrekt - men OOXML er det muligt for andre kontorpakker at implementere fuld understøttelse af filformaterne i Microsoft Office. Det var tidligere ikke muligt, da Microsoft holdt kortene meget tæt på kroppen.

den synes blot uoverkommelig

Det er din egen konklusion og du mangler stadig at komme blot i nærheden af at kunne retfærdiggøre den.

Microsoft selv siger jo, at de tidligst (!) kan have deres egen version klar i år 2015

Hvor har du en officiel udtalelse fra Microsoft om dette? Jeg har aldrig hørt Microsoft tale om disse ting - faktisk afviser de på det bestemteste at give nogen form for tal, hvis jeg forsøger at få sådan et - selv uofficielt. Når det sandsynligvis er korrekt, at de ikke kan have S implementeret i morgen, så skyldes det nok mere deres release-cyklusser for Microsoft Office.

  • 0
  • 0
#31 Stig Libori

Angående understøttelsen af *doc og *ooxml i Ooo: før vi tog beslutningen om et delvist skift til Ooo lavede vi naturligvis en række tests på, hvor god Ooo var til at åbne vores allerede eksisterende dokumenter korrekt. Vores konklusion var, at det går bedst med *doc, men at der også er mange formateringsproblemer når Ooo åbner *doc.

http://www.version2.dk/artikel/12343-microsoft-ooxml-kommer-tidligst-i-2015 er artiklen der fortæller, at MS selv siger ooxml strict tidligst bliver implementeret i år 2015 - hvilket jeg også ser som en dokumentation af, at det ikke er helt enkelt at implementere. Personligt kunne jeg næppe nå bare at læse dokumentationen for formatet inden da......

  • 0
  • 0
#32 Jesper Lund Stocholm Blogger

Hej Stig,

før vi tog beslutningen

Hvem er "vi" ?

er artiklen der fortæller, at MS selv siger ooxml strict tidligst bliver implementeret i år 2015

(jeg vidste godt, at du ville hitte netop den artikel)

Artiklen er på ingen måde en autoritativ kilde fra Microsoft. Det er OSL, der har hørt rygter fra en ukendt kilde, der var til et møde et møde, som OSL ikke deltog i, at en unavngivet MS-ansat "højt på strå" har udtalt etellerandet.

Så du må stadig gerne hitte en autoritativ kilde fra Microsoft, der har sagt, at de først kan implementere S i 2015.

  • 0
  • 0
#33 Stig Libori

"Vi" er min arbejdsplads.

"Så du må stadig gerne hitte en autoritativ kilde fra Microsoft, der har sagt, at de først kan implementere S i 2015."

Næ - jeg behøver bare tro på artiklen! Har du en autoritativ udtalelse fra MS om, at de har tænkt sig at implementere strict før 2015?

  • 0
  • 0
#34 Jesper Lund Stocholm Blogger

Hej Stig,

Næ - jeg behøver bare tro på artiklen!

Ok - men eftersom Microsoft ikke selv er citeret direkte i artiklen med navnet på en person, så mente du jo reelt

"OSL har sagt, at Microsoft ikke implementerer S før 2015"

og ikke

"Microsoft har sagt, at de ikke implementerer S før 2015"

Ikk' ?

PS: det er rigtigt farligt at forlade sig på noget som helst som OSL siger om OOXML eller ODF. Sandheden (og den faglige integritet) er nemlig tilsyneladende det første offer i OSLs krig imod OOXML.

  • 0
  • 0
#36 Anders Rosendal

Jesper:

Måske har han ikke nævnt en dato, men jasper fra ms har jo direkte sagt at ooxml-s i praksis er værdiløs/ubrugelig.

Så det er godt nok til mig. Sjovt nok var du meget stille lige omkring DEN specifikke artikel :-)

Så eftersom ooxml-s er ubrugelig i praksis ser jeg ingen grund til at vælge ooxml, straight, +t eller +s. Og hvorfor skal der være så mange? Kunne de ikke nøjes med bare 1 ligesom ODF?

  • 0
  • 0
#39 Jesper Lund Stocholm Blogger

Hej Anders,

Måske har han ikke nævnt en dato, men jasper fra ms har jo direkte sagt at ooxml-s i praksis er værdiløs/ubrugelig.

At S skulle være værdiløs må stå for MS' egen regning. Jeg er voldsomt uenig.

Så eftersom ooxml-s er ubrugelig i praksis ser jeg ingen grund til at vælge ooxml, straight, +t eller +s.

Ok - og det er helt fair, at du har den holdning. Jeg er uenig i den - men du har naturligvis al mulig ret til at mene, hvad du mener.

Jeg synes så blot, at man skal være ved sin holdning og erklære den åbent (ikke henvendt direkte til dig). Jeg er overbevist om, at størstedelen af "jer" herinde, der nu siger "ODF + S" reelt er fuldstændigt enig med dig - at en "ODF only" løsning er den eneste acceptable løsning. Jeg tror også, at I udmærket ved (i modsætning til visse politikere), at "ODF+S" reelt er det samme som "ODF only" og at "ODF+S" udelukkende er "sugar-coating", der skal få "ODF only" til at glide nemmere ned for partier som SF, DF, Enh og andre.

Og hvorfor skal der være så mange? Kunne de ikke nøjes med bare 1 ligesom ODF?

Med ODF 1.2 har man fra 2 til 6 conformance-klasser (alt afhængigt af, hvordan man kigger på det), så vi skal sikkert igennem hele den samme diskussion igen, når ODF 1.2 skal indkluderes i den danske liste af godkendte dokumentformater.

:o)

  • 0
  • 0
#40 Anders Rosendal

At S skulle være værdiløs må stå for MS' egen regning. Jeg er voldsomt uenig.

Jeg vælger så at tro ms ved mere om det end dig :-)

Jeg er overbevist om, at størstedelen af "jer" herinde, der nu siger "ODF + S" reelt er fuldstændigt enig med dig - at en "ODF only" løsning er den eneste acceptable løsning.

Lige nu er min største grund til at feje ooxml-s af bordet at ms ikke SELV tror på den. Og den ikke findes endnu. Jeg synes det er ret ligegyldigt at vælge noget som ikke findes.

Jeg tror også, at I udmærket ved (i modsætning til visse politikere), at "ODF+S" reelt er det samme som "ODF only"

Ja lige nu. Men kun indtil ms vælger at køre på "even playing field" som de siger derovre :-P Det er jo 100% op til ms at blive færdig med ooxml-s. Hvis de brugte mindre tid på at konkurrence forvridende forretningsmetoder så ville det måske gå lidt hurtigere.

  • 0
  • 0
#42 Peter Stricker

Jesper, tror du at OOXML Strict vil være standard formatet i Microsoft Office inden 2015? Eller i det mindste, at det vil være muligt at gemme og læse dokumenter i S inden 2015.

Det er efterhånden et stykke tid siden årstallet 2015 første gang blev nævnt, og Microsoft har endnu ikke givet os grund til at tro at det bliver tdligere.

  • 0
  • 0
#43 Flemming Bjerke

Stocholm: ... det er rigtigt farligt at forlade sig på noget som helst som OSL siger om OOXML eller ODF. Sandheden (og den faglige integritet) er nemlig tilsyneladende det første offer i OSLs krig imod OOXML.

MEN det er endnu mere farligt at forlade sig på noget som helst som Microsoft og deres håndlangere siger om OOXML eller ODF. Sandheden (og den faglige integritet) er nemlig tilsyneladende det første offer i Microsofts og deres lejesvendes krig for at påtvinge myndigheder, borgere og virksomheder deres Microsoftkontrollerede formater i så mange versioner som overhovedet muligt.

"OSL har sagt, at Microsoft ikke implementerer S før 2015"

Mon ikke OSL er for pæne og optimistiske. Med alle MS's latterlige forsøg på at sabotere den ISO-forbedrede standard OOXML-fæstrict, og med den tid MS foreløbig har brugt på at ikke at få færdigudviklet og implementeret OOXML, bliver strict nok ikke implementeret før 2020.

Henrik Jensen: Microsoft havde allerede XML formater til Word + Excel i beta version af Microsoft Office 2003 før at OpenOffice.org XML blev sendt til OASIS. Frigivelse af MS Office 2003 med XML formater var i april 2003, ca. 2 år for at ODF blev godkendt i OASIS.

Og SÅ, faldt MS i søvn og gav sig til at rode rundt med XML og påståede åbne standard uden der rigtig blev noget ud af det. Imens kørte ODF-toget videre. Og nu vil Helge Sander og regeringen kompensere for Microsofts uduelighed ved at sikre at Microsoft kan påtvinge staten og borgerne deres ufærdige Transitional OOXML - ikke den af ISO-forbedrede Strict-standard. Knald i låget!

Stocholm: ... jeg er ikke vidende om funktionalitet i OOXML, der kræver reverse-engineering af Microsoft Office.

Jesper, du har vist igen glemt hvad din gode ven IBM's Rob Weir sagde:

Weir: The point is that the text of the published standard is deeply flawed and does not correctly describe what Office 2007 actually writes out. ... Office 2010 extends T with dozens of new elements that are not documented at all in the ISO standard. So Office 2010 = T + Proprietary elements. This is how they add support for the new features of Office 2010. http://www.version2.dk/artikel/13123-sf-sender-dokumentformater-i-folket...

Stocholm: .... selv ITSTs pilotprojekter havde kun en enkelt fast og overbevisende konklusion - nemlig at hvis man udelukkende ønskede god interop, så var det bedste valg DOC og hverken ODF eller OOXML.

Det er jo en helt fantastisk indsigtfuld og overraskende konklusion: Det mest udbredte format giver bedst interoperabilitet (med sig selv)! Men den udelukker på ingen måde at det mest hensigtsmæssige fremtidige format er ODF!!! For når det bliver dominerende, vil ODF have bedst interoperabilitet.

  • 0
  • 0
#44 Carsten Sonne

Vijay Prasad skrev:

"At ODF ikke kan beskrive al funktionalitet i Microsoft Office."

.TXT kan heller ikke, men MS Office håndterer .TXT helt fint :-)

Det er vel kun det "omvendte problem" (hvis MS Office ikke kan beskrive al funktionalitet i ODF), som er et muligt reelt problem (for MS, ikke for standarden).

Smukt !

Der er intet der forhindre en kontor pakket i at kunne gemme i andre formater, deriblandt egne proprietære formater.

Hvis en standard blot beskriver en så stor mængde basis funktionalitet at det i praksis dækker almene behov, så er den fuldstændig.

Specielle behov kan dækkes med specielle løsninger, som det i øvrigt allerede bliver gjort alle mulige andre steder.

En standard er en laveste fællesnævner. En standards vigtigste opgave er at sikre [b]interoperabilitet[/b].

  • 0
  • 0
#45 Jesper Lund Stocholm Blogger

Hej Flemming,

Jesper, du har vist igen glemt hvad din gode ven IBM's Rob Weir sagde:

Mjaeh ... en "extension" er jo pr. definition ikke en del af standarden.

Men Microsofts udvidelser til OOXML er dokumenterede her:

http://msdn.microsoft.com/en-us/library/dd773189.aspx

(for Word)

Men du behøver nu ikke at går til Rob for at få den information. Jeg har selv skrevet en hel del om det tilbage i august lige her på version2:

http://www.version2.dk/artikel/11715-office-2010-is29500--det-loese

Det er ikke noget nyt (eller hokus-pokus) i dette, og jeg er lidt overrasket over, at du er så forbavset/indigneret over det nu, når det har været kendt (af alle) længe.

Min udtalelse "der er ikke noget i OOXML, der kræver reverse-engineering af Microsoft Office" er i øvrigt helt valid.

Det er jo en helt fantastisk indsigtfuld og overraskende konklusion: Det mest udbredte format giver bedst interoperabilitet (med sig selv)!

Husk at det er ITSTs konklusion og ikke "min helt egen".

  • 0
  • 0
#46 Jesper Lund Stocholm Blogger

Hej Carsten,

Smukt !

Der er intet der forhindre en kontor pakket i at kunne gemme i andre formater, deriblandt egne proprietære formater.

Øhm - jeg har aldrig sagt, at Microsoft Office ikke kan gemme et dokument som ODF - mig bekendt går det ganske godt med at gøre dette. Tilvarende kan Microsoft Office også gemme et dokument som TXT.

Det er derimod evident, at når Microsoft Office gemmer et dokument som TXT, så sker det et informationstab - uagtet, at TXT-filen i sig selv er "valid".

  • 0
  • 0
#47 Anders Rosendal

Øhm - jeg har aldrig sagt, at Microsoft Office ikke kan gemme et dokument som ODF - mig bekendt går det ganske godt med at gøre dette. Tilvarende kan Microsoft Office også gemme et dokument som TXT.

Jamen hvis ms office både kan skrive og læse ODF og der ingen problemer er, så er ODF jo det bedste valg. På den måde kan dokumenterne bruges af alle.

  • 0
  • 0
#48 Jesper Lund Stocholm Blogger

Hej Anders,

Det er derimod evident, at når Microsoft Office gemmer et dokument som TXT, så sker det et informationstab - uagtet, at TXT-filen i sig selv er "valid".

Min sætning

"Det er derimod evident, at når Microsoft Office gemmer et dokument som TXT, så sker det et informationstab - uagtet, at TXT-filen i sig selv er "valid"."

Gælder også for ODF.

Det drejer sig ikke om, hvorvidt det er muligt for Microsoft Office at gemme en valid ODF-fil - for det kan den sagtens. Det drejer sig om, at ODF ikke kan indeholde al funktionalitet i Microsoft Office, og derfor vil der ske informationstab, når man via Microsoft Office forsøger at gemme et dokument som ODF.

  • 0
  • 0
#50 Anders Rosendal

Det drejer sig om, at ODF ikke kan indeholde al funktionalitet i Microsoft Office, og derfor vil der ske informationstab, når man via Microsoft Office forsøger at gemme et dokument som ODF.

Og? Jeg kan ikke se pointen. Jeg er sikker på ms kan finde på MANGE ting som ODF ikke kan repræsentere. F.eks. et tag som angiver hvilken bil jeg kører i. Jeg ville faktisk blive overrasket hvis der var tale om 1 til 1 mapping.

Hvilket informationstab mener du, er det aller vigtigste i ms office som går tabt når man gemmer som ODF?

Follow-up: ms kunne jo have gået med i arbejdet da ODF blev til. Så havde de undgået alle disse problemer. Så ris til egen røv.

  • 0
  • 0
#52 Jesper Lund Stocholm Blogger

Hej Anders,

Follow-up: ms kunne jo have gået med i arbejdet da ODF blev til. Så havde de undgået alle disse problemer. Så ris til egen røv.

Follow-up: Sun kunne jo have startet med at implementere OOXML, da den blev overgivet til ECMA som Apple, Novell og Corel gjorde det i stedet for at sidde på hænderne og håbe på, at hele verden ville kaste sig i grus over argumentationsstrømmen fra Rob Weir og Pamela Jones. Så havde de haft en velfungerende OOXML-implementering i dag, og vi havde ikke haft behov for at have denne diskusion. Så ris til egen røv.

  • 0
  • 0
#54 Deleted User

Follow-up: Sun kunne jo have startet med at implementere OOXML, da den blev overgivet til ECMA som Apple, Novell og Corel gjorde det i stedet for at sidde på hænderne og håbe på, at hele verden ville kaste sig i grus over argumentationsstrømmen fra Rob Weir og Pamela Jones. Så havde de haft en velfungerende OOXML-implementering i dag, og vi havde ikke haft behov for at have denne diskusion. Så ris til egen røv.

Hvorfor skulle de det? der var jo allerede en standard, ODF.

  • 0
  • 0
#55 Vijay Prasad

Det drejer sig om, at ODF ikke kan indeholde al funktionalitet i Microsoft Office, og derfor vil der ske informationstab, når man via Microsoft Office forsøger at gemme et dokument som ODF.

Eh?

1) Hvorfor skal MS Office's funktionalitet have særstatus når man ønsker at fremme frit leverandørvalg?

2) XX-Office n+1 vil givetvis indeholde funktionalitet som man ikke havde tænkt på i XX-Office n - hvorfor så have en standard?

Mvh,

  • 0
  • 0
#57 Jesper Lund Stocholm Blogger

Hej Jon,

Hvorfor skulle de det? der var jo allerede en standard, ODF.

Sun skulle implementere OOXML, da det er dokumentformatet i verdens mest udbredte kontorpakke. Ja, de skulle sådan set blot leve op til deres egen "mission statement":

http://wiki.services.openoffice.org/wiki/Strategic_Marketing_Plan#Micros...

Har du hittet på en definition af "vigtig"?

  • 0
  • 0
#58 Jesper Lund Stocholm Blogger

Hej Vijay,

1) Hvorfor skal MS Office's funktionalitet have særstatus når man ønsker at fremme frit leverandørvalg?

Det skal den heller ikke "fordi den er Microsoft Office". Men vi skal naturligvis tage hensyn til, at hvis vi gennemtrumfer en "ODF-only"-løsning, så vil det betyde informationstab for selv dokumenter, der måtte regnes for simple - for 90% af brugerne af kontorpakker i den offentlige forvaltning.

Når vi nu har muligheden for at (til)vælge et dokumentformat, der ikke har den "uhensigtsmæssighed", der samtid er åbent og frit for alle at implementere - hvorfor skulle vi så ikke vælge det også?

2) XX-Office n+1 vil givetvis indeholde funktionalitet som man ikke havde tænkt på i XX-Office n - hvorfor så have en standard?

Det samme kan du argumentere for med ODF/OOo - nemlig at der er features i ODF 1.2, der ikke var tænkt på i ODF 1.0 . Mener du seriøst, at man dermed skulle afholde sig fra at standardisere dokumentformater i det hele taget?

  • 0
  • 0
#59 Anders Rosendal

Det samme kan du argumentere for med ODF/OOo - nemlig at der er features i ODF 1.2, der ikke var tænkt på i ODF 1.0 . Mener du seriøst, at man dermed skulle afholde sig fra at standardisere dokumentformater i det hele taget?

Nej, det var DIN konklusion.

Du skrev tidligere: Vi kan ikke vælge format X, da Y indeholder elementer som ikke kan gemmes i format X.

Har du ændret mening og synes det er okay at vi vælger en standard som kan betyde informationstab?

  • 0
  • 0
#60 Carsten Sonne

Hej Jesper,

Øhm - jeg har aldrig sagt, at Microsoft Office ikke kan gemme et dokument som ODF - mig bekendt går det ganske godt med at gøre dette. Tilvarende kan Microsoft Office også gemme et dokument som TXT.

Det er derimod evident, at når Microsoft Office gemmer et dokument som TXT, så sker det et informationstab - uagtet, at TXT-filen i sig selv er "valid".

Ja. Ville det ikke være fint, hvis man kunne finde en lidt højere fællesnævner end TXT, der kunne sikre interoperabilitet, apropos standard ?

  • 0
  • 0
#62 Jens Christian Damgaard

Du laver en fejl, hvis du tror, at Suns plugin til Microsoft Office er en fuld implementering af ODF. Den er lige så fejlbehæftet som ODF-implementeringen i Microsoft Office 2007. Henrik Jensen har tidligere gået Jens Christian på klingen omkring nogle af de ting, som han ikke kunne få til at virke, men Jens Christian klappede desværre i som en østers.

Du husker forkert! Jeg debatterede meget længe med Henrik Jensen (kig i arkiverne!) vedr. "problemer" med SUN ODF Plugin. Henrik var bl.a. meget optaget af at blinkende tekst blinker på en anden måde i MS Office m. SUN Plugin.

Det korte af det lange er, at vi ikke oplever problemer i det daglige med virkelige arbejdsdokumenter og ODF-plugin. Men på den anden side anvender vi heller ikke blinkende tekst i Region Midtjylland ;-)

  • 0
  • 0
#66 Jesper Lund Stocholm Blogger

Hej Jon,

Hvorfor skal jeg det, vi bliver alligevel ikke enig om hvad der er vigtigt. Så i stedet kan du svare på hvilken VIGTIG information synes DU der går tabt?

Jeg brugte ikke ordet "vigtig" - det var dig. Du kan ikke forvente, at jeg skal svare på dit usagn om "hvilken VIGTIG information går tabt" (din egen fremhævning), når du ikke vil fortælle, hvad "VIGTIG" er for dig.

Useriøst.

  • 0
  • 0
#67 Anders Rosendal

Her:

Det drejer sig ikke om, hvorvidt det er muligt for Microsoft Office at gemme en valid ODF-fil - for det kan den sagtens. Det drejer sig om, at ODF ikke kan indeholde al funktionalitet i Microsoft Office, og derfor vil der ske informationstab, når man via Microsoft Office forsøger at gemme et dokument som ODF.

Min primære anke imod S er, at den ikke er implementeret i markedet.

Så ODF som ER implementeret i markedet har du ingen kvaler med?

  • 0
  • 0
#68 Anders Rosendal

Jeg brugte ikke ordet "vigtig" - det var dig. Du kan ikke forvente, at jeg skal svare på dit usagn om "hvilken VIGTIG information går tabt" (din egen fremhævning), når du ikke vil fortælle, hvad "VIGTIG" er for dig.

Hvor længe kan du blive ved med at snakke udenom? :-)

Håber du kan svare på dette: Mener du at der er information som går tabt? Mener du at der er vigtig information som går tabt? (Din personlige mening) Hvis Ja: Hvilken? Hvis Nej: Hvilken ikke-vigtig information går tabt?

  • 0
  • 0
#69 Jesper Lund Stocholm Blogger

Hej Anders,

Det drejer sig ikke om, hvorvidt det er muligt for Microsoft Office at gemme en valid ODF-fil - for det kan den sagtens. Det drejer sig om, at ODF ikke kan indeholde al funktionalitet i Microsoft Office, og derfor vil der ske informationstab, når man via Microsoft Office forsøger at gemme et dokument som ODF.

(pas på, nu beskylder Flemse dig snart for citatfusk)

:o)

Anyway - jeg har aldrig brugt ovenstående som argument for ikke at vælge ODF - ja, jeg har faktisk aldrig argumenteret for, at ODF ikke skulle vælges.

Så ODF som ER implementeret i markedet har du ingen kvaler med?

Udover nogle smådetaljer omkring den konkrete valgte version, så "nej". Jeg er helt enig med Konkurrencestyrelsen og ekspertpanelet, der anbefaler valg af ODF som ét af to dokumentformater.

  • 0
  • 0
#75 Anders Rosendal

I stedet for at kaste dig over mig, bør du stille spørgsmålet til Jon - alt den stund, at det var ham, der bragte det på bane.

Ja og nu spørger jeg dig. Lad mig høre: På rent børnehave niveau forventer du at Jon skal svare på et spørgsmål. Alt imens du selv nægter at svare på samme spørgsmål. Er det korrekt forstået?

Synes DU at ooxml er en god standard?

Sådan som jeg har forstået det kan ODF klare alle informationer i ms office som bliver brugt af det offentlige. Derfor når du kan gå ind for ODF som den officielle standard, så er der ikke brug for at tilvælge en ekstra standard.

  • 0
  • 0
#76 Deleted User

suk altså Jesper. Men du bliver jo nok ved med at tale uden om indtil jeg prøver at definere hvad der er vigtigt. Og så når jeg har defineret det så taler du med garanti alligevel uden om. Så jeg vælger den nemme definition af vigtig.

Nogle af de ting som ODF indeholder er vigtige. Andre ting som ODF indeholder er ikke vigtige, MEN ODF mangler ikke noget som jeg synes er vigtigt.

Det er derfor nu op til dig at bevise at ODF mangler nogle ting som er vigtige. Nu har du ikke flere undskyldninger.

  • 0
  • 0
#77 Jesper Lund Stocholm Blogger

Hej Anders,

På rent børnehave niveau forventer du at Jon skal svare på et spørgsmål. Alt imens du selv nægter at svare på samme spørgsmål. Er det korrekt forstået?

Alt den stund, at Jon selv bragte ordet "vigtigt" på banen (og valgte at bruge versaler til at understrege vigtigheden), synes jeg vi skal give Jon mulighed for først at fortælle, hvad han lægger i ordet "vigtigt".

Hvis jeg giver dig min opfattelse af ordet "vigtigt", så er jeg sikker på, at Jon vil bruge det til at fise ud af endnu en tangent med vendinger som "det er da ikke vigtigt" eller lignende. Derfor synes jeg, at vi skal give Jon plads til først at svare på spørgsmålet - inden jeg risikerer at ødelægge det hele.

:o)

Jon?

  • 0
  • 0
#78 Deleted User

Hvis jeg giver dig min opfattelse af ordet "vigtigt", så er jeg sikker på, at Jon vil bruge det til at fise ud af endnu en tangent med vendinger som "det er da ikke vigtigt" eller lignende. Derfor synes jeg, at vi skal give Jon plads til først at svare på spørgsmålet - inden jeg risikerer at ødelægge det hele.

Jesper altså. Der skal selvfølgelig være plads til en debat og uoverensstemmelser i hvad forskellige mennesker synes er vigtigt.

  • 0
  • 0
#79 Jesper Lund Stocholm Blogger

Hej Jon,

Jesper altså. Der skal selvfølgelig være plads til en debat og uoverensstemmelser i hvad forskellige mennesker synes er vigtigt.

Det er jeg helt enig i - men du har jo endnu ikke sagt, hvad du mener er vigtigt. Du har sagt, at "hvis det ikke er i ODF, så er det ikke vigtigt".

Overordnet set mener jeg ikke, at det giver mening at tale om ting, der "objektivt set er vigtige". Derimod kan en givet egenskab være vigtig i den konkrete anvendelse.

Ex: Ændringssporing er måske ikke anvendt af alle, men hvis vi taler om "redigerbare dokumenter" (og det gør vi vel her?), så må man som minimum kræve, at ændringer i dokumentet bliver registreret. Her fejler ODF, da ændringssporing i ODF ikke kan registrere selv simple ting som ændringer i tabeller.

Ex: Formattering af punktopstillinger regnes nok af nogen som i kategorien "ikke vigtigt", men hvis man skriver et dokument med teksten "I listen herunder har jeg med rødt markeret de forslag, som jeg vil anbefale bestyrelsen at afvise" - så er det vel i denne brug relevant, at farvelægningen ikke forsvinder.

Ex: Anvendelsen af meta-data (via fx DublinCore) er ikke konvertibelt imellem OOXML og ODF, for i ODF har man modificeret nogle af de felter, man - øhm - "genbruger" fra DublinCore. I OOXML er anvendte elementer ikke modificeret. Hvis man ikke anvender disse elementer, så er det jo ligegyldigt - men hvis man anvender dem, så kan man vel med rette forvente, at de og deres funktionalitet bibeholdes?

Ex: I OOXML har man en konstruktion, der hedder "content controls", der er en måde at indkapsle bruger-indtastede data på, så de udskilles fra den dokumentcentriske markup. Der findes ikke noget tilsvarende i ODF. Igen - hvis man bruger dem, så vil man med rette forvente, at de ikke forsvinder.

(og nej, dette er ikke en udtømmende liste)

  • 0
  • 0
#80 Deleted User

Ændringsspor er vigtige. Men kan implementeres i versions kontrol systemet. Fx. subversion. Har du et template dokument som kan bruges til test af din påstand om at ODF ikke understøtter det?

Formateringen kan klares på anden måde. Fx. ved at dele listen op i 2 dele, eller have prioriterede numre. Jeg forstår dog ikke at du siger at farvelægningen forsvinder? Forsvinder? Taler du nu om konvertering?

meta-data konvertibelt? Altså, når der kun skal være 1. dokument format, så er det da lige meget om man kan konvertere imellem dem.

ikke forsvinder? og bruger dem? Igen virker det som om du taler om konvertering imellem 2 forskellige formater.

Jeg synes det er tåbeligt. Selvfølgelig skal der kun være en standard.

  • 0
  • 0
#82 Jens Christian Damgaard

Jesper:

Ex: Formattering af punktopstillinger regnes nok af nogen som i kategorien "ikke vigtigt", men hvis man skriver et dokument med teksten "I listen herunder har jeg med rødt markeret de forslag, som jeg vil anbefale bestyrelsen at afvise" - så er det vel i denne brug relevant, at farvelægningen ikke forsvinder.

Har netop prøvet ovennævnte i praksis, og har ikke kunnet konstatere tab af formatering ved punktopstilling i odf. (OpenOffice <-> MS Office 2003)

Kan du give et hint til hvordan du fremprovokerer fejlen?

  • 0
  • 0
#83 Anders Rosendal

Formattering af punktopstillinger regnes nok af nogen som i kategorien "ikke vigtigt", men hvis man skriver et dokument med teksten "I listen herunder har jeg med rødt markeret de forslag, som jeg vil anbefale bestyrelsen at afvise" - så er det vel i denne brug relevant, at farvelægningen ikke forsvinder.

Jeg har lige testet med OOo 3.1.1. Den gemmer fint en punktopstilling hvor jeg har markeret nogle med rød tekst. Så ODF kan godt håndtere punktopstillinger med farve.

Andre har afvist resten af dine punkter. Har du lyst til at komme med nogle nye påstande om ting i ms office som ikke kan repræsenteres af ODF formatet?

Vær opmærksom på der er forskel på "ms office gemmer forkert" og så "kan ikke repræsenteres af ODF formatet".

  • 0
  • 0
#84 Christian Nobel

Follow-up: Sun kunne jo have startet med at implementere OOXML, da den blev overgivet til ECMA som Apple, Novell og Corel gjorde det i stedet for at sidde på hænderne og håbe på, at hele verden ville kaste sig i grus over argumentationsstrømmen fra Rob Weir og Pamela Jones. Så havde de haft en velfungerende OOXML-implementering i dag, og vi havde ikke haft behov for at have denne diskusion. Så ris til egen røv.

Og der manipuleres videre i vanlig stil.

Jeg tror lige vi skal se på (simplificeret version) historikken:

1 - slut 2002: ODF TC dannet i OASIS, i hvilken der var rigtig mange medlemmer, og hvor MS også var inviteret - men nej det lå sandelig under MS' værdighed.

Tiden går, og verden begynder at stille krav til åbne standarder for dokumentformater.

2 - slut 2005: MS føler presset i sådant et omfang at OOXML TC dannes i ECMA, primært med MS og MS partnere som medlemmer.

Og så er det at JLS åbenbart mener, jamen så skal SUN juble og underkaste sig MS' forsøg på at kuppe deres egen "standard" igennem. Hvorfor skal tingene altid foregå på MS' præmisser og på en underlig bagvendt måde?

Herudover så viser praksis at ODF fungerer glimrende som dokumentformat, og så er det muligt at man ikke kan specificere at 17 kolonnes 5 celle skal udfyldes med grønne marsmænd der spiser lyserøde papirklips, men til almindeligt praktisk arbejde er det særdeles velanvendeligt.

Men alt dette går sikkert hen over hovedet på visse folk i deres Babelstårn - eller der er måske mere tale om en minaret, hvor komikerparret Bojsen&Stockholm står og jaller i toppen, i et desperat ønske om at kortslutte demokratiet, så deres nyttige idiot, den såkaldte "videnskabsminister" straks kommer rendende med logrende hale, i forhåbning om den store Bojsen vil kaste nogle gnaveben ned til ham.

/Christian

  • 0
  • 0
#85 Paw Hermansen

Jeg tror Helge Sander er ligeglad med det "mere grundlæggende spørgsmål, der handler om open eller closed source". Jeg tror, at da Helge Sander mødtes med Bill Gates for fem år siden, lavede de en studehandel, hvor Microsoft lovede at stikke penge i et dansk privat-universitet mod at Helge Sander støtter Microsoft, for eksempel ved at gå ind for software patenter i EU, og nu, ved at støtte Microsofts OOXML.

  • 0
  • 0
#86 Jesper Lund Stocholm Blogger

Hej Jon,

Ændringsspor er vigtige. Men kan implementeres i versions kontrol systemet. Fx. subversion. Har du et template dokument som kan bruges til test af din påstand om at ODF ikke understøtter det?

Som Jens Christian tidligere gjorde opmærksom på, så er den virkelige verden anderledes end den (for nogle) ønskelige. Derfor er det muligt, at "feature x" kan erstattes af "værktøj y" (ex web formular i stedet for tekstdokumenter til indsamling af data eller SVN i stedet for ændringssporing), men det er en del af dagligdagen at arbejde med disse ting i tekstdokumenter i OOo, Microsoft Office etc, så det står nok ikke lige for døren at skulle udskifte ændringssporing med SVN eller Hg (som i øvrigt nok ville være et bedre alternativ end SVN.

Jon, Anders, Jens:

Formateringen kan klares på anden måde. Fx. ved at dele listen op i 2 dele, eller have prioriterede numre. Jeg forstår dog ikke at du siger at farvelægningen forsvinder? Forsvinder? Taler du nu om konvertering?

Fejl i formattering af punktopstillinger er blot et symptom på en grundlæggende forskel på OOXML og ODF for hvordan lister beskrives. Jeg har lavet en fil i Word 2007 (SP2), som jeg har lagt på http://idippedut.dk/page/Test-files.aspx . Microsoft Office muliggør styling af list-items på en måde, som ODF ikke anvender. Derfor kan denne konstruktion ikke overføres til ODF, og farvelægning kan mistes - selvom man godt isoleret set kan lave en rød prik i en liste i ODF.

Til jeres orientering, så har jeg prøvet at se, om der dog ikke var et værktøj, der var "kreativt" nok til at kunne gøre et eller andet med det, men forgæves. Jeg har prøvet med

Microsoft Office 2003 Sun plugin Microsoft Office 2003 CA plugin Microsoft Office 2007 SP2 NeoOffice OOo Lotus Symphony

Eneste program, der kunne vise listen korrekt var iWork '09 Pages - men den understøtter jo også netop OOXML.

Hvis man har lyst til at bruge en 8-10 timer på at forstå, hvorfor "nummererede lister" ikke er så trivielt som man skulle tro, så kan man kigge på http://blogs.msdn.com/ericwhite/archive/2009/12/15/working-with-numberin...

meta-data konvertibelt? Altså, når der kun skal være 1. dokument format, så er det da lige meget om man kan konvertere imellem dem.

Du spurgte efter forskelle på funktionalitet i Microsoft Office 2007 (OOXML) og i ODF, og den giver jeg dig. Uanset hvordan du vender og drejer det, så vil du få et problem, hvis dit persisteringsformat er anderledes end funktionaliteten i den interne objektmodel i dit værktøj. Det samme problem er jo også til stede, hvis du vi gemme et dokument i OOXML fra Microsoft Office 2007 og herefter åbne det i Microsoft Office 2003.

Et (tænkt) eksempel kunne være:

Hvis man i "værktøj X" understøtter 3 slags meta-data (oprettet_af, applikation, sidst_ændret_af) men "format y" kun understøtter "oprettet_af" og "applikation" - hvordan vil du så undgå at miste information?

ikke forsvinder? og bruger dem? Igen virker det som om du taler om konvertering imellem 2 forskellige formater

Nej - jeg taler om en feature i Microsoft Office 2007, der ikke modsvares af features i ODF. Derfor kan denne ikke umiddelbart persisteres i ODF.

Anders:

Andre har afvist resten af dine punkter.

De er da ikke på nogen måde blevet afvist. Jeg blev bedt om en række punkter, hvor information kunne gå tabt ved anvendelse af ODF i Microsoft Office. Den gav jeg - ja, jeg forudså endda den præcise reaktion du kan se ovenfor, nemlig at man ville sige at, det er ikke vigtigt, "det er ligemeget" eller - som her - hvor Jon foreslår at man bruger SNV til registrering af ændringssporing.

  • 0
  • 0
#88 Anders Rosendal

De er da ikke på nogen måde blevet afvist. Jeg blev bedt om en række punkter, hvor information kunne gå tabt ved anvendelse af ODF i Microsoft Office.

Nej. Jeg er sikker på at der er ting ved ODF som går tabt hvis du i en standard office prøver at åbne et ODF dokument. Ja faktisk er ms office så dårligt det ikke engang kan læse filen!

Jeg personligt spurgte:

Andre har afvist resten af dine punkter. Har du lyst til at komme med nogle nye påstande om ting i ms office som ikke kan repræsenteres af ODF formatet?

Vær opmærksom på der er forskel på "ms office gemmer forkert" og så "kan ikke repræsenteres af ODF formatet".

Men prøv igen.

  • 0
  • 0
#89 Vijay Prasad

De er da ikke på nogen måde blevet afvist. Jeg blev bedt om en række punkter, hvor information kunne gå tabt ved anvendelse af ODF i Microsoft Office. Den gav jeg - ja, jeg forudså endda den præcise reaktion du kan se ovenfor, nemlig at man ville sige at, det er ikke vigtigt, "det er ligemeget" eller - som her - hvor Jon foreslår at man bruger SNV til registrering af ændringssporing.

Jeg er klar over at vi argumenterer i ring, men må alligevel lige sparke ind.

Der vil ligemeget hvad man vælger være tale om hvad du kalder "informations tab". "Informations tab" er, som det også er påpeget her, et meget diffust begreb. Hvad er information? Tekst der mangler i dokumentet, farve-fremhævelser der mangler, 1px forskellig linjeafstand på skærmen?

Generelt, er jeg imod at vælge en pseudo-standard der imiterer en bestemt kontorpakke's funktionalitet. (Ja, jeg er klar over at det er sådan med både ODF og OOXML(T)). Hvis det er umuligt at få andet, så bør man liste en "must have", "nice to have", "don't care" i fht. hvad man ønsker af dokumentudvekling. (altså, ikke en liste hvor noget er markeret med rødt :) ).

I det perspektiv mener jeg Jon's foreslag om "SNV" (s/SNV/SVN/g) giver fint mening.

Mvh,

  • 0
  • 0
#90 Jens Christian Damgaard

Jesper

Som Jens Christian tidligere gjorde opmærksom på, så er den virkelige verden anderledes end den (for nogle) ønskelige.

Mener du som i eksemplerne med ODF interoperabilitet hvor der for eksempel ikke er problemer med farver og punktopstilling i den virkelige verden, men hvor bl.a. både du og Henrik Jensen bliver ved med at med at påstå det modsatte?

Jeg kan uden problemer lave en punktopstilling med 4 punkter. Markere det tredje punkt med rødt, og herefter sendet det til Word. Der er stadig rød markering.

Sådan arbejder mennesker ude i virkeligheden.

Derimod er ideen om at lave én punktopstilling med forskelligt farvede bullets så langt ude at det virker nærmest desperat.

Hvis du skal helt derud for at finde "fejl" i ODF-standarden, er der vist ikke ret meget at komme efter.

  • 0
  • 0
#92 Jesper Lund Stocholm Blogger

Hej Anders,

Jeg er sikker på at der er ting ved ODF som går tabt hvis du i en standard office prøver at åbne et ODF dokument. Ja faktisk er ms office så dårligt det ikke engang kan læse filen!

Hvis du kigger på filen jeg har lavet, så vil du se, at det er et OOXML-dokument og ikke et ODT-dokument. Du har jo nemlig ret i, at Microsoft Office (2007) ikke har verdens bedste ODF-implementering.

Derfor har jeg lavet filen i OOXML-format (baseret på dit input) og forsøgt at konvertere det til ODF via en række andre programmer/plugins end Microsoft Office.

Så nej, jeg har ikke prøvet at åbne et ODF-dokument i Microsoft Office (2007). Jeg har anvendt en feature i Microsoft Office 2007, der (naturligvis) kan persisteres i OOXML og vist, at denne feature mistes ved konvertering til ODF.

Jeg har også forklaret, hvorfor jeg mener Jon tager fejl i sine antagelse omkring de andre punkter, så din udtalelse om, at de "er blevet afvist" er lidt noget pjat.

  • 0
  • 0
#93 Jesper Lund Stocholm Blogger

Hej Jens Christian,

Mener du som i eksemplerne med ODF interoperabilitet hvor der for eksempel ikke er problemer med farver og punktopstilling i den virkelige verden, men hvor bl.a. både du og Henrik Jensen bliver ved med at med at påstå det modsatte?

Jeg nøjes nu ikke med at påstå det - jeg har jo fx vist det her.

Du svarede jo i øvrigt (meget belejligt) kun på det ene af mine eksempler - hvad siger du til resten?

Jeg kan uden problemer lave en punktopstilling med 4 punkter. Markere det tredje punkt med rødt, og herefter sendet det til Word. Der er stadig rød markering.

Ja, og det skrev jeg jo også netop ovenfor, at man uden problemer kan (farve en prik rød i ODF). Problemet opstår ved, at OOXML i dette tilfælde er rigere end ODF (og der er bestemt områder, hvor det er omvendt).

Mit eksempel med metadata var lidt til din ære, for jeg var bange for, at du ikke kunne greje det ellers.

Jeg gentager det lige:

[i]"Et (tænkt) eksempel kunne være:

Hvis man i "værktøj X" understøtter 3 slags meta-data (oprettet_af, applikation, sidst_ændret_af) men "format y" kun understøtter "oprettet_af" og "applikation" - hvordan vil du så undgå at miste information?"[/i]

I dette tilfælde understøtter OOo og ODF "oprettet af" og "applikation", og derfor kan et dokument uden videre konverteres til formatet for "værktøj X". Men det går ikke omvendt, for så mistes "sidst ændret af".

Hvis du skal helt derud for at finde "fejl" i ODF-standarden, er der vist ikke ret meget at komme efter.

Jeg er klar over, at du har en rygmarvs-reaktion, der fortæller dig, at når jeg nævner ODF, så er det pr. definition et angreb på ODF. Det er dog ret langt fra sandheden. Dette er blot et eksempel på, hvor information mistes, hvis man tvinger en bruger af Microsoft Office til at gemme i ODF-formatet. Vær også opmærksom på, at det jo for mange er en ubetinget fordel, at ODF ikke er så "bloated" som OOXML, så du kan sagtens se mit eksempel som en indirekte ros til ODF.

  • 0
  • 0
#95 Jesper Lund Stocholm Blogger

Hej Carsten,

Implementerende software.

OK - grundlæggende mener jeg ikke, at jeg skal stille mig som dommer over, om feature X i kontorpakke Y er "vigtig nok". Det vigtige for mig er at sikre, at man har frit valg af kontorpakker og dermed frit valg af funktionalitet. Hvis man gennemtrumfer et ODF-only-valg (eller ODF+OOXML-S-valg), så fratager man det frie valg for de, der har brugsmønstre, der bla. inkluderer features, der ikke findes i ODF.

  • 0
  • 0
#96 Deleted User

OK - grundlæggende mener jeg ikke, at jeg skal stille mig som dommer over, om feature X i kontorpakke Y er "vigtig nok".

Jesper, hvis man skal følge en standard så skal man ikke begynde at indføre ny extra funktionalitet som ikke er dækket af standarden.

HELE, det her problem er opstået fordi Microsoft ikke selv har fremlagt dokumentation for deres office data format for mange år siden.

Hvis de havde fremlagt dokumentationen så alle kunne lave kontorpakker som kan læse og skrive Microsofts format, så ville der ikke have været samme pres på at få en standard. 1 standard.

Selvfølgelig skal der kun være en standard, alt andet er spild af resourcer.

  • 0
  • 0
#97 Christian Nobel

så fratager man det frie valg for de, der har brugsmønstre, der bla. inkluderer features, der ikke findes i ODF.

So what (i øvrigt en bizar måde pludselig at whine om frie valg fra en MS lakaj)?

Hvis jeg synes det er sjovt at køre en højre styret Aston Martin, så kan det også give mig problemer med at køre på danske veje (omend det kan lade sig gøre).

Men selvfølgelig, vi skal bare tilpasse det danske vejnet så det passer til højrestyrede biler - sic!

/Christian

  • 0
  • 0
#98 Jesper Lund Stocholm Blogger

Hej Jon,

Jesper, hvis man skal følge en standard så skal man ikke begynde at indføre ny extra funktionalitet som ikke er dækket af standarden.

Hvorfor ikke? Det fungerer da ganske fint med andre standarder som C++ og lignende.

I SC22 (programming languages) har man den kongstanke, at man ikke standardiserer udvidelser til fx c++, hvis de ikke har bevist deres værd i markedet. Man laver dermed ikke "standardisation by committee". Jeg kan ikke se, hvorfor dette pludseligt er et kæmpe problem, når vi taler om dokumentformater.

En standard skal i mine øjne danne basis for innovation og udvikling af ny funktionalitet. Det skal ikke være en spændetrøje, der hæmmer innovation.

Det virker også på nøjagtig samme måde med fx HTML, der også i de sidste 10 år har fungeret som en basis for innovation. Ja, tag du bare JavaScript med, der lige er godkendt i en ny version.

HELE, det her problem er opstået fordi Microsoft ikke selv har fremlagt dokumentation for deres office data format for mange år siden

Ja, og nu har vi så fået den dokumentation men nu nægter vi at bruge den? Med mindre du har en tidsmaskine, som vi kan bruge til at rejse tilbage i tid, så er det altså den verden vi lever i i dag - uanset om vi kan lide det eller ej.

Hvis de havde fremlagt dokumentationen så alle kunne lave kontorpakker som kan læse og skrive Microsofts format, så ville der ikke have været samme pres på at få en standard

Jeps - og vi kan jo bla. takke ODF og OOo for, at Microsoft endelig har nosset sig sammen til at dokumentere deres dokumentformat. Det må vi ikke glemme!

Jeg er klar over, at mange ønsker at straffe Microsoft for ikke at have været med i ODF-arbejdet "fra starten", men [b]jeg[/b] er i hvert fald ikke klar til at ofre brugerne af Microsoft Office (og de features de anvender i kontorpakken) på "ODF-retfærdighedens hellige alter" - hvilket vil være konsekvensen af at indføre en ODF-only-løsning.

Så kan man jo naturligvis vælge at opføre sig som Christian Nobel, der mere og mere lyder som Erik i "Erik og Else" fra Rytteriet på P2 [0], men jeg synes faktisk, at det giver mere mening at kæmpe på den bane, der rent faktisk findes.

:o)

[0] http://www.dr.dk/P2/Rytteriet/20080414123548.htm

  • 0
  • 0
#100 Deleted User

Ja, og nu har vi så fået den dokumentation men nu nægter vi at bruge den? Med mindre du har en tidsmaskine, som vi kan bruge til at rejse tilbage i tid, så er det altså den verden vi lever i i dag - uanset om vi kan lide det eller ej.

Jamen Microsoft har jo ikke dokumenteret deres rigtige format, altså det format som de rent faktisk bruger. De har dokumenteret noget andet. Den der tvetydighed kan vi ikke bruge. De må lave arbejdet ordentligt, og enten dokumentere det de rent faktisk bruger, eller rent faktisk bruge det som de dokumentere.

Du kan ikke direkte sammenligne med C++ eller HTML. Brugen af C++ er noget helt andet end dokumentstandarder. Programmører som bruger C++ ved en HEL del mere om computere end gennemsnits folket som bruger kontorpakker.

Og du kan slet ikke bruge HTML, for netop her kan vi jo også se problemet. Hjemmesider som er lavet til internet explorer 5 og muligvis 6 fungerer ikke med nyere browsere, for slet ikke at tale om browsere fra andre fabrikanter. Hvor er det frie browser valg?

De udvidede funktioner må kunne klares ved at dokumentere udvidelserne som foreslag til dokumentstandarden, og så TYDELIGT gøre brugeren opmærksom på når der ikke bliver gemt i standard formatet, incl. grafisk visning af hvilken funktionalitet som mistes når andre åbner dokumentet i andre kontorprogrammer som kun følger standarden. Gerne allerede når man bruger den udvidede funktionalitet.

Standard formatet skal i øvrigt være default gemme, og ikke det udvidede format.

  • 0
  • 0
#102 Jesper Lund Stocholm Blogger

Hej Jon,

Jamen Microsoft har jo ikke dokumenteret deres rigtige format, altså det format som de rent faktisk bruger.

ISO OOXML er det samme som dokumentformatet i Microsoft Office 2007.

Du kan ikke direkte sammenligne med C++ eller HTML. Brugen af C++ er noget helt andet end dokumentstandarder. Programmører som bruger C++ ved en HEL del mere om computere end gennemsnits folket som bruger kontorpakker.

Min pointe var ikke brugerne men den måde ny funktionalitet kommer ind i standarden. Du skal i hvert fald ikke bilde mig ind, at den gennemsnitlige c++-programmør er up-to-date på det løbende arbejde i ISO SC22 :o)

Og du kan slet ikke bruge HTML, for netop her kan vi jo også se problemet.

At fungere som en basis for innovation har også uheldige sider, det er klart. Men hvis du kigger på de ting, der virkeligt har revolutioneret "Web" igennem de sidste 5 år, så er det primært AJAX og "multimedie". AJAX er i langt overvejende grad baseret på en browser-specifik feature fra Microsoft, som Mozilla og andre valgte at kopiere. Tilsvarende er "multimedie" slet ikke specificeret i HTML 4* men anvender det generiske plugin "object"-element.

Nu har disse ting dog vist deres værd i markedet, og multimedie bliver nu en integreret del (first class citizen) i HTML og det, der oprindeligt var en browserspecifik feature i IE er nu en del af en W3C-standard.

http://www.w3.org/TR/XMLHttpRequest2/

De udvidede funktioner må kunne klares ved at dokumentere udvidelserne som foreslag til dokumentstandarden, og så TYDELIGT gøre brugeren opmærksom på når der ikke bliver gemt i standard formatet, incl. grafisk visning af hvilken funktionalitet som mistes når andre åbner dokumentet i andre kontorprogrammer som kun følger standarden. Gerne allerede når man bruger den udvidede funktionalitet.

Standard formatet skal i øvrigt være default gemme, og ikke det udvidede format.

Held og lykke med at få Sun og Microsoft til at gøre dette :-)

  • 0
  • 0
#103 Jesper Lund Stocholm Blogger

Hej Jon,

Jeg har spekuleret på at lave en mundtlig debat aften.

Det var da en super idé :o)

Måske kan du få hjælp fra nogle af Version2s community-builders til arrangementet? Jeg ved i hvert fald, at Tine Havkrog tidligere overfor mig fortalte, at de gerne ville hjælpe til.

  • 0
  • 0
#104 Anders Rosendal

Vi skal da snart drikke øl igen, skal vi ikke?

Jeg synes hellere du skulle skære lidt ned.

Anyways. Åbenbart kan man ikke konvertere en rød prik til ODF. Det kan enten skyldes formatet eller den måde du konverterer på. Hvis det er det største problem med ODF, så tror jeg helt ærligt at seriøse firmaer overlever.

  • 0
  • 0
#106 Jesper Lund Stocholm Blogger

Hej Anders,

Hvis det er det største problem med ODF, så tror jeg helt ærligt at seriøse firmaer overlever.

Det er bestemt ikke "det største problem med ODF", men det er åbenbart det eneste, du har fokuseret på.

Har du ikke tidligere sagt at ooxml-s er en del af ooxml?

Undskyld - lad mig omformulere det:

"[b]ISO/IEC 29500:2008 (OOXML) beskriver dokumentformatet i Microsoft Office 2007[/b]"

Tak :o)

  • 0
  • 0
#107 Anders Rosendal

Det er bestemt ikke "det største problem med ODF", men det er åbenbart det eneste, du har fokuseret på.

Jeg så ikke andre? Du siger at ms office har et problem med deres konvertering mht. versionering. Men det er jo et problem med ms-office og ikke ODF. Kan du nævne en ting som du i det daglige bruger som ikke kan repræsenteres med ODF?

Lad mig spørge omvendt: Hvis jeg bruger ODF og vil konvertere til noget som ms-office kan læse, hvilke ting kan ms-office så ikke læse? Jeg er sikker på listen er lang. Så pointen er: fordi ms ikke understøtter en fælles standard er der problemer. Måden at undgå det på er at vælge EEN standard og så bruger alle den.

"ISO/IEC 29500:2008 (OOXML) beskriver dokumentformatet i Microsoft Office 2007"

Det skal nok passe. Her gætter jeg på det er ooxml-t?

  • 0
  • 0
#108 Jesper Lund Stocholm Blogger

Hej Anders,

Jeg så ikke andre? Du siger at ms office har et problem med deres konvertering mht. versionering.

Nej - jeg siger, at ændringssporing i ODF ikke er så rigt som ændringssporing i OOXML.

Men det er jo et problem med ms-office og ikke ODF.

Nej - det er et eksempel på, at der er funktionalitet i OOXML, der ikke modsvares i ODF Kan du nævne en ting som du i det daglige bruger som ikke kan repræsenteres med ODF?[/quote] Fra mit daglige arbejde?

[b]Ændringssporing: [/b]

I ODF kan ikke registreres, hvis en række i en tabel slettes.

I ODF registreres ændringer i indholdsfortegnelse ikke

[b]CustomXML:[/b]

ODF understøtter ikke en ren adskillelse af layout og information

[b]Content controls:[/b]

ODF understøtter ikke "content controls".

Hvis jeg bruger ODF og vil konvertere til noget som ms-office kan læse, hvilke ting kan ms-office så ikke læse?

Mig bekendt er vejen "ODF -> Microsoft Office 2007" ganske venfungerende. Det er den anden vej problemet opstår. Grunden til dette er, at der er væsentligt mere funktionalitet, der er i OOXML men ikke i ODF end omvendt.

Det skal nok passe. Her gætter jeg på det er ooxml-t?

'T' er ikke en specifikation men en conformance clause.

  • 0
  • 0
#109 Christian Nobel

Så kan man jo naturligvis vælge at opføre sig som Christian Nobel, der mere og mere lyder som Erik i "Erik og Else" fra Rytteriet på P2 [0], men jeg synes faktisk, at det giver mere mening at kæmpe på den bane, der rent faktisk findes.

Nu hører jeg aldrig radio, så jeg derfor kan jeg ikke kommentere det.

Men hvis du mener at det at kæmpe på den bane der faktisk findes betyder at banen skal være fabrikat MS, ja så er vi altså uenige al den stund jeg mener at der børe være et og kun et dokumentformat, nemlig ODF - og at MS så har problemer med det er jeg dybest set bedøvende ligeglad med.

Ved at vælge ODF og kun ODF sendes der er kraftigt signal til både offentlige myndigheder og MS om at se at tage sig sammen, og så behøver myndighederne ikke spekulere i om det skal være strict eller depriciated.

Hvis der så endelig skal indgås kompromisser omkring MSXML, [b]så SKAL det være strict[/b] - at det så i praksis betyder ODF da strict jo i følge spindoktor Bojsen er ubrugeligt, ja det kan man så kun græde tørre tårer over.

Og det er altså væsentlig billigere at anskaffe sig kontorpakker der passer til ODF end omvendt!

Vi skal da snart drikke øl igen, skal vi ikke?

Du kender præmissen!

/Christian

  • 0
  • 0
#110 Carsten Sonne

Hej Jesper,

Det vigtige for mig er at sikre, at man har frit valg af kontorpakker og dermed frit valg af funktionalitet.

OOXML-T er det modsatte af et frit valg. Det vil i praksis betyde at man skal have MS Office for at kunne udveksle dokumenter "uden tab at informationer".

Min pointe er jo netop at OOXML-T på ingen måden sikre interoperabilitet.

  • 0
  • 0
#111 Anders Rosendal

Nej - jeg siger, at ændringssporing i ODF ikke er så rigt som ændringssporing i OOXML.

Hvis opera laver deres browser som læser en anden slags html, så IE ikke kan læse deres sider. Hvor er problemet så?

Understøtter ms-office 2007 hele ISO/IEC 29500:2008 (OOXML)?

  • 0
  • 0
#112 Deleted User

Det var da en super idé :o)

Måske kan du få hjælp fra nogle af Version2s community-builders til arrangementet? Jeg ved i hvert fald, at Tine Havkrog tidligere overfor mig fortalte, at de gerne ville hjælpe til.

Det behøver jeg slet ikke. Hvis jeg gider så arrangerer jeg det bare i DKUUG.

Mit største problem er nok at finde den rette til at tale for ODF.

  • 0
  • 0
#113 Deleted User

ISO OOXML er det samme som dokumentformatet i Microsoft Office 2007.

De bruger jo ikke Strict.

Min pointe var ikke brugerne men den måde ny funktionalitet kommer ind i standarden. Du skal i hvert fald ikke bilde mig ind, at den gennemsnitlige c++-programmør er up-to-date på det løbende arbejde i ISO SC22 :o)

Men programmører skal heller ikke dele kode med andre uden for deres egen lille udviklings gruppe. Og selv da kan de godt finde ud af at portere fra den ene C++ til den anden C++ hvis de skal bruge en stump delt kode.

Kontordokumenter skal deles imellem gud og hvermand. Derfor skal det bare virke, og der skal partu kun være 1 standard.

Held og lykke med at få Sun og Microsoft til at gøre dette :-)

Det er relativt nemt. 1) vælg 1 standard og kun 1. 2) stil krav om at kontorpakken til det offentlige opfører sig på den måde.

  • 0
  • 0
#115 Jesper Lund Stocholm Blogger

Hej Carsten,

OOXML-T er det modsatte af et frit valg. Det vil i praksis betyde at man skal have MS Office

Næeh - det betyder, at man skal have fat i en kontorpakke, der har implementeret OOXML-T.

for at kunne udveksle dokumenter "uden tab at informationer".

Ok - så det er vigtigt at kunne udveksle dokumenter "uden tab af informationer"?

Hvis man gennemtrumfer et ODF-only-valg, så vil der så sandelig også ske informationstab - det vil blot ikke ske på modtagetidspunktet men på afsendertidspunktet (hvor der gemmes i ODF) - hvis man er iblandt de 90% af markedet, der bruger Microsoft Office.

  • 0
  • 0
#118 Deleted User

Ok - det er da trist - omend ret forventeligt.

Ja, det er ikke alle nørder som formår at debatere klart og tydeligt. De få der er kender måske ikke ODF så godt.

Husk at få det optaget på video!

Det kan også hæmme folks lyst til at tale frit.

  • 0
  • 0
#120 Christian Nobel

Hvis man gennemtrumfer et ODF-only-valg, så vil der så sandelig også ske informationstab - det vil blot ikke ske på modtagetidspunktet men på afsendertidspunktet (hvor der gemmes i ODF) - hvis man er iblandt de 90% af markedet, der bruger Microsoft Office.

Hvilket vel også er det rigtige tidspunkt informationstab (eventuelt) skal ske! Og brugeren får vel en advarsel om at der kan ske tab.

Herudover er der så det at sige at 90% af brugerne kommer slet ikke ud i de afkroge hvor det er risiko for tab - [b]slet ikke hvis MS kunne se at få nosset sig sammen til at implementere ODF i stedet for at forsætte en kampagne for deres eget pseudoåbne format[/b]

Endvidere er det sygt at du stadig ikke fatter at hvis ikke man demonterer MS' greb om dokumentformatet, så vil MS blive ved med at dominere markedet i al evighed - og vi andre vil blive ved med at skulle slås op ad bakke hver eneste dag, fordi vores OO brugere ikke kan åbne OOXML documenter, fordi OO ikke har en kinamands chance!

Og så er OOXML i øvrigt et skodformat, se bare mit eksempel om inkonsistens!

/Christian

  • 0
  • 0
#122 Deleted User

Informationstab på marginalerne? ODF-valg betyder indskrænkning af det frie valg "i markedet". Vælg det ene og vælg det andet.

Prøv lige at læse overskriften på den artikel, som kommenteres. "Svaret på krig om dokumentformater er politisk".

JA. Fordi det her i virkeligheden ikke handler om, hvorvidt det ene eller det andet eller det syvogtyvende format er det "rigtige" eller ej.

Valget er meget enklere. Skal vi som salig Glistrup (næsten) formulerede det, erstatte teknologiministeriet med en telefonsvarer, der lakonisk meddeler, at "vi har overgivet os til Microsoft. Send pengene til Bill Gates og lad os være i fred" - eller skal vi forsøge at slå et slag for, at det i hvert fald i Danmark er danskerne (politikere og andet godtfolk) der bestemmer og ikke ledelsen af en multinational koncern?

Og tag så stilling til, hvilke af de aktuelle formater, som bedst formidler det valg lige nu og lige her. Uanset hvor længe folk skændes, så er der ingen objektiv middelvej her. Er man for det ene, kan man ikke også være for det andet. Og omvendt.

  • 0
  • 0
#126 Deleted User

Det synes jeg nu ikke (åbenhed og sådan noget) - men jeg glæder mig til at høre mere om arrangementet, når du evt har fået noget mere konkret på bordet.

Det ville være nemmere hvis nogen fortalte mig hvem der kan tale godt for ODF.

Ellers så må jeg jo bare sætte dig op imod Dolph ;-)

"multinational koncern" - som i "IBM"?

Det er for lavt det der Jesper. Ja, IBM er multinational, men de kontrollerer hverken ODF eller Open Office.

  • 0
  • 0
#127 Jesper Lund Stocholm Blogger

Hej Jon,

Det ville være nemmere hvis nogen fortalte mig hvem der kan tale godt for ODF.

Du kunne også prøve noget alternativt - nemlig at sætte Jasper til at snakke om OOXML og mig til at snakke om ODF?

Ellers så må jeg jo bare sætte dig op imod Dolph ;-)

Hr. Nobel? Hr. Kjærsgaard?

:o)

Det er for lavt det der Jesper. Ja, IBM er multinational, men de kontrollerer hverken ODF eller Open Office.

Jeg vil faktisk vove den påstand, at IBMs (fremadrettede) indflydelse på ODF er langt større end Microsofts indflydelse på OOXML.

  • 0
  • 0
#128 Carsten Sonne

Hej Jesper,

"OOXML-T er det modsatte af et frit valg. Det vil i praksis betyde at man skal have MS Office."

Næeh - det betyder, at man skal have fat i en kontorpakke, der har implementeret OOXML-T

Det er vist påstand mod påstand.

Hvis man gennemtrumfer et ODF-only-valg, så vil der så sandelig også ske informationstab.

Det vil ske i det øjeblik man gemmer sit Word dokument på ens harddisk på samme måde, som det allerede gør i Word, hvis du vil gemme i f.eks. *.doc format.

Det i sig selv, er ikke et problem område for standarden. Standardens problem område er derimod at gøre det som en standard gør, nemlig at sikre interoperabilitet.

Interoperabilitet i denne sammenhæng vil sige, at modtageren af dokumentet kan forvente en korrekt fortolkning af filens indhold, når han/hun åbner filen i et stykke vilkårligt software.

  • 0
  • 0
#129 Jesper Lund Stocholm Blogger

Hej Carsten,

Det i sig selv, er ikke et problem område for standarden. Standardens problem område er derimod at gøre det som en standard gør, nemlig at sikre interoperabilitet.

Det har du helt ret i - en standard defineres ret stringent i forhold til sig selv.

Men det har naturligvis betydning, hvis anvendelsen af en standard bevirker de problemer, som jeg bla. har listet ovenfor. Eller sagt med andre ord:

[b]

Selv hvis en standard var at regne som Guds eenborne søn og i sig selv var perfekt, ren, tysk og hvid, så er det i forbindelse med en politisk anbefaling naturligvis en faktor, hvis anvendelsen af den giver problemer for bare 50% af brugerne, der skal bruge den. Det kan og bør naturligvis påvirke en beslutning af, om det nu giver mening at bruge den konkrete standard som eneste mulighed.

[/b]

  • 0
  • 0
#130 Anders Rosendal

Jeg mener ikke at vi i Danmark skal binde os til eet firma. Derudover er det dumt at betale mange mange milliarder for ms-office.

Det kan alt sammen løses ved at vælge ODF. Der er ingen dårlige ting ved valget. Med et plugin kan virksomheder/brugere læse/skrive dokumenterne. I løbet af få år er de få forskelligeheder løst. (Rød prik i liste f.eks.)

Igen: Det kan ikke være Danmarks problem hvis ms ikke kan/vil understøtte det eneste åbne dokumentformat der findes.

  • 0
  • 0
#131 Jesper Lund Stocholm Blogger

Hej Anders,

Jeg mener ikke at vi i Danmark skal binde os til eet firma.

Enig :o)

Derudover er det dumt at betale mange mange milliarder for ms-office.

Mig bekendt drejer det sig trods alt ikke om milliarder, men jeg synes ikke selve prisen er så relevant i sig selv.

Det kan alt sammen løses ved at vælge ODF.

fnis

Det bliver altså ikke mere korrekt, selvom du bliver ved med at gentage det.

I løbet af få år er de få forskelligeheder løst. (Rød prik i liste f.eks.)

Hvis vi et øjeblik antager, at forskellene kan løses (hvilket jeg ikke er enig med dig i), hvad skal vi så gøre, indtil "de få år" er gået? Er det bare "touch luck" for brugerne af Microsoft Office?

Resultatet af "Gem i ODF fra Microsoft Office" bliver aldrig rigtigt godt, hvis der ikke kommer features i ODF fra Microsoft Office. Der kommer sikkert til at gå 5 år fra ISO-godkendelse af ODF 1.0 til ISO-godkendelse af ODF 1.2. ODF 1.2 er vel reelt nu gået i "feature-freeze", så disse ting kan først komme med i ODFNext.

Hvad tror du selv er en realistisk tidsramme for at disse ting kommer med i en godkendt udgave af ODF?

Igen: Det kan ikke være Danmarks problem hvis ms ikke kan/vil understøtte det eneste åbne dokumentformat der findes.

Hey - hedder du reelt Morten Kjærsgaard?

:o)

Anyways - mig bekendt understøtter Microsoft fint OOXML.

  • 0
  • 0
#133 Anders Rosendal

Hvis vi et øjeblik antager, at forskellene kan løses (hvilket jeg ikke er enig med dig i), hvad skal vi så gøre, indtil "de få år" er gået? Er det bare "touch luck" for brugerne af Microsoft Office?

Du mener jo det fint med et monopol, så nu får du problemerne. Hvis alle brugte Open Office kunne man bare ændre koden og gøre så OO understøttede standard X.

Hvis jeg ikke ejer ms-office og SKAT sender mig et docx dokument jeg ikke kan åbne er det så bare "touch luck" ?

  • 0
  • 0
#136 Jesper Lund Stocholm Blogger

Hej Anders,

Kilde: http://en.wikipedia.org/wiki/Office_Open_XML#Application_support

Så det du skriver er ifølge wikipedia forkert.

Du er sgu for sjov i dag - så nu er Wikipedia blevet en autoritativ kilde?

Der citeres 4 forskellige artikler som "kilde" til udsagnet. For det første er de allesammen fra omkring 2008, og for det andet (og endnu vigtigere) er der ingen af dem, der kan bruges til at retfærdiggøre udsagnet om, "Microsoft, which currently has no products which are compatible with ISO/IEC 29500".

Kildekritik, kære Anders ... kildekritik.

Det er relativt let at verificere, at om et dokument "implementerer en standard". Det er reelt blot en schema-validering du skal lave.

  • 0
  • 0
#137 Jesper Lund Stocholm Blogger

Hej Anders,

Du mener jo det fint med et monopol

Kilde, tak!

De understøtter en lille del og det er den del som ikke kan bruges til noget.

Faktisk er en implementering ifht T langt den største del af OOXML. Deltaet imellem T og S er funktionelt og markup-mæssigt utroligt småt.

(hvilket jo ikke er det samme som, at det ikke er et vigtigt delta)

At du omtaler T som "en lille del" fastslår i øvrigt, at du ikke ved specielt meget om OOXML.

(men det er ok - du er i godt selskab, overliggeren ligger ikke specielt højt herinde for viden om OOXML)

  • 0
  • 0
#138 Anders Rosendal

Jeg stoler mere på wikipedia end dig. Så du må være ufattelig utroværdig :-) Understøtter ms-office ooxml-s?

"Det er relativt let at verificere, at om et dokument "implementerer en standard". Det er reelt blot en schema-validering du skal lave"

Nej det er ikke så nemt, men det er du åbenbart ikke smart nok at til at regne ud? Bare fordi jeg laver eet dokument og det validerer betyder jo ikke at alle dokumenter vil validere vel?

ms-office understøtter ikke ooxml-s og siden det er den åbne standard ODF er oppe imod, så synes jeg ikke alle mulige krumspring med røde prikker har nogen relevans.

Men hvis du mener wikipedia tager fejl, skal du være velkommen til at rette siden og komme med en bedre kilde. Du skriver at kilderne er fra 2008 som om det var noget skidt. Hvornår kom ms-office 2007 ud? Men send gerne et bedre link, så vil jeg gøre mit bedste for at være kildekritisk.

  • 0
  • 0
#139 Jesper Lund Stocholm Blogger

Hej Anders,

(og nu glemte jeg noget)

Hvis jeg ikke ejer ms-office og SKAT sender mig et docx dokument jeg ikke kan åbne er det så bare "touch luck" ?

Jamen, gør SKAT da det?

Er der ikke på nuværende tidpunkt, at Hr. Nobel skrider ind og gjalder "hvis og hvis og hvis ... min røv er spids!!!!!"?

... eller det er måske kun, når [i]jeg[/i] bruger ordet?

  • 0
  • 0
#140 Anders Rosendal

At du skulle synes monopolisme er en god ting VED jeg jo ikke. Kun at du er 1 blandt 3 som har arbejdet SÅ hårdt for microsoft at du har fået en fin titel. Men det siger (i min bog) også lidt.

Faktisk er en implementering ifht T langt den største del af OOXML. Deltaet imellem T og S er funktionelt og markup-mæssigt utroligt småt.

Kilde! (Hey, jeg kan også)

Ja delta'et er jo ikke mindre end det vil tage microsoft 5 år at implementere! (Du må gerne finde en kilde der modsiger det, da jeg kun har fundet tallene 2015 og 2017)

Ud over det er ooxml-s jo ubrugelig (Kilde Jasper fra microsoft)

  • 0
  • 0
#141 Anders Rosendal

"Jamen, gør SKAT da det?"

Hvis ooxml bliver standard formatet skulle man tro det.

Men ellers må du gerne svare på: Hvis jeg ikke ejer ms-office og SKAT sender mig et docx dokument jeg ikke kan åbne er det så bare "touch luck" ?

  • 0
  • 0
#142 Jesper Lund Stocholm Blogger

Hej Anders,

Jeg stoler mere på wikipedia end dig. Så du må være ufattelig utroværdig :-)

Det må jeg så lære at leve med :o)

Understøtter ms-office ooxml-s?

Jeg vil ikke afvise, at Microsoft Office i simple dokumenter kun bruger strict indhold, men generelt er svaret "nej".

Bare fordi jeg laver eet dokument og det validerer betyder jo ikke at alle dokumenter vil validere vel?

Nej - men hvis det er så åbenlyst, at Microsoft Office 2007 ikke implementerer OOXML, så vil det nemmeste i verden være at danne et dokument, der fejler. Dermed har du skudt den teori ned.

ms-office understøtter ikke ooxml-s og siden det er den åbne standard ODF er oppe imod, så synes jeg ikke alle mulige krumspring med røde prikker har nogen relevans.

Skægt - lige før indikerede du, at ODF var "det eneste åbne dokumentformat" :o)

Men hvis du mener wikipedia tager fejl, skal du være velkommen til at rette siden og komme med en bedre kilde.

Jeg kan love dig for, at jeg ikke vil røre Wikipedia med en ildtang - og specielt ikke noget, der har med hverken ODF eller OOXML at gøre.

Du skriver at kilderne er fra 2008 som om det var noget skidt. Hvornår kom ms-office 2007 ud?

2008 er relevant, da OOXML blev godkendt i april 2008 og offentliggjort i november det år. Derfor er det min vurdering, at de færreste på tidspunktet for artiklerne (fx maj 2008) havde et reelt billede af, hvordan standarden kom til at se ud - og de sider der henvises til, var ikke en del af standardiseringsarbejdet i det foregående år i ISO.

Konkret for kilderne:

ODF Alliance (20. februar 2008): Titlen siger jo faktisk, at der kun én implementering af OOXML men længere nede påstår det modsatte. Artiklen er i øvrigt fra før BRM-mødet i Geneve.

Microsoft (21. maj 2008): siden nævner ikke, at Microsoft Office ikke implementerer ISO 29500 - snarere det modsatte.

Computerworld (27. maj 2008): Artiklen omhandler faktisk ikke om Microsoft Office 2007 implementerer 29500.

Andy Updegrove (21. maj 2008): Artiklen er reelt en opfølgning på artiklen fra MS men den taler heller om, hvorvidt Microsoft Office 2007 implementerer 29500. Den taler i stedet om, hvornår Microsoft vil implementer de nye ting, der blev tilføjet specifikationen.

  • 0
  • 0
#143 Jesper Lund Stocholm Blogger

Hej Anders,

Kilde! (Hey, jeg kan også)

Ændringerne i OOXML på mødet i Geneve kan du hente på http://www.adjb.net/index.php?entry=entry080306-082306

Der er vel omkring 200 sider i alt (hvis min hukommelse ikke svigter mig). Ændringerne ifht omstrukturering er ikke engang nævnt i alle dokumenter.

Hele specifikationen (dvs S og T) er på næsten 6000 sider i alt.

Ja delta'et er jo ikke mindre end det vil tage microsoft 5 år at implementere! (Du må gerne finde en kilde der modsiger det, da jeg kun har fundet tallene 2015 og 2017)

Det har jeg ikke, for Microsoft har mig bekendt aldrig udtalt sig konkret om specifikke datoer for implementering af S - men jeg gider simpelthen ikke forholde mig længere til OSLs deperate stråmand omkring hvad en hemmelig kilde fortalte at en unavngivet MS-mand havde sagt på et møde, som OSL ikke deltog i.

Ud over det er ooxml-s jo ubrugelig (Kilde Jasper fra microsoft)

Det må stå for Jaspers egen regning - jeg er ikke enig med ham.

Men ellers må du gerne svare på: Hvis jeg ikke ejer ms-office og SKAT sender mig et docx dokument jeg ikke kan åbne er det så bare "touch luck" ?

I beslutningsforslag og senere konkret aftale imellem Regioner, KL og regeringen, tales der om "modtagekrav". Jeg kan derfor ikke se, hvorfor [b]afsendelse[/b] nu er relevant.

  • 0
  • 0
#145 Jeppe Rørbæk

Jeg synes også afsendelse er relevant, men vel ikke i denne forbindelse. Aftalen går på hvad myndigheder skal kunne modtage, og hvis det aftales at de skal kunne modtage både ODF og OOXML, gør det vel netop, at den største del af forbrugerene i praksis slipper for et tvangsskifte til en anden kontorpakke (hvad enten de benytter en MSOffice pakke, eller en der native benytter ODF som filformat). Som udgangspunkt synes jeg godt man kan argumentere for, at et sådant valg stiller forbrugeren bedre end hvis kun ét format kan accepteres. Og hvis kun ét format kan accepteres, er det vel en rimelig forventning, at det dækker alle relevante scenarier, uden at medføre gener for (for)brugerne. Mvh

  • 0
  • 0
#146 Anders Rosendal

Jeg vil ikke afvise, at Microsoft Office i simple dokumenter kun bruger strict indhold, men generelt er svaret "nej".

Jeg forstår ikke helt. Indeholder ooxml ikke ooxml-s? I så fald understøtter ms-office ikke ooxml. Måske en del af ooxml, men bestemt ikke det hele.

Skægt - lige før indikerede du, at ODF var "det eneste åbne dokumentformat" :o)

Eneste der bliver brugt. Af nogen.

2008 er relevant, da OOXML blev godkendt i april 2008 og offentliggjort i november det år. Derfor er det min vurdering, at de færreste på tidspunktet for artiklerne (fx maj 2008) havde et reelt billede af, hvordan standarden kom til at se ud

Hvordan kan en kontopakke fra 2007 overholde en standard der blev lavet i april 2008?

Hele specifikationen (dvs S og T) er på næsten 6000 sider i alt.

Så T er 5800 sider og S 200 sider. Og alligevel kan ms ikke sige hvornår de er færdige. Enten lyver du eller også lyver ms når de siger de ikke kan blive klar. Helt ærligt.

Det må stå for Jaspers egen regning - jeg er ikke enig med ham.

Så er det nu jeg skal øve mig i kildekritik.

Teknologidirektør hos Microsoft, Jasper Bojsen vs. tilfældig som i egne ord ikke er ansat eller på anden vis forbundet med microsoft.

Jeg tror i denne sag må teknologidirektøren hos Microsoft vide bedst hvordan deres produkter virker. Hvorfor er du uenig med Jasper? Hvad kan ooxml-s bruges til?

Hvornår er ms færdig med at implementere ooxml-s? Har de nogen planer? Teknologidirektøren hos Microsoft siger jo at ooxml-s er ubrugeligt, så måske har de helt droppet planerne om ooxml-s.

  • 0
  • 0
#147 Deleted User

Jeg taler for, at man foretager et politisk valg i en politisk problemstilling (langt, langt oppe i rækken af kommentarer) - og ikke et tilsyneladende teknisk valg i en politisk problemstilling. Og jeg taler for at frigøre sig fra de multinationales alt for store indflydelse. Hvilken får Jesper Lund Stocholm til at vrænge "multinational koncern" - som i "IBM"?" Tjahh ...

Mit svar er det ganske enkle: Ja ... det gælder også IBM. Jesper, hvis du havde læst hvad jeg skrev i stedet for at reagere på rygmarven, så ville det ikke have været nødvendigt at spørge. Hvilket jo uvilkårligt får visse til at tænke, ikke?? I hvert fald mig.

  • 0
  • 0
#148 Jesper Lund Stocholm Blogger

Hej Anders,

I så fald understøtter ms-office ikke ooxml. Måske en del af ooxml, men bestemt ikke det hele.

Svaret på "implementerer jeg OOXML" skal findes i conformance-clauses i 29500. Der er to af dem (S og T), hvoraf Microsoft implementerer den ene.

Hvordan kan en kontopakke fra 2007 overholde en standard der blev lavet i april 2008?

Det er da ikke noget problem. Eksempelvis regner jeg da også med, at OOo allerede i dag overholder "fremtidens" ODF 1.2, når den engang bliver vedtaget i ISO - selvom der nok går noget tid endnu . Det er blot et spørgsmål om at sikre sig, at kompatibiliteten bliver bibeholdt.

Så T er 5800 sider og S 200 sider.

Nej.

Hvorfor er du uenig med Jasper? Hvad kan ooxml-s bruges til?

Som jeg hører Microsofts primære anke imod S, er den at man med S ikke kan sikre at ældre dokumenter (DOC, ECMA-376 1st ed) kan overføres uden tab til det åbne xml-baserede OOXML-format.

Det har han jo ret i - men på et eller andet tidspunkt bør vi vælge at slå en streg i sandet. Her er Jens Hørlück og jeg jo meget enige. Jens mener blot, at vi skal slå stregen nu, jeg mener vi skal slå stregen, når S esisterer i markedet.

:o)

Teknologidirektøren hos Microsoft siger jo at ooxml-s er ubrugeligt, så måske har de helt droppet planerne om ooxml-s.

Det er da muligt - men det må du jo spørge Microsoft om.

  • 0
  • 0
#149 Jesper Lund Stocholm Blogger

Hej Jan,

Jesper, hvis du havde læst hvad jeg skrev i stedet for at reagere på rygmarven, så ville det ikke have været nødvendigt at spørge

Jeg forholdt mig faktisk [i]præcist[/i] til, hvad du skrev. Du nævnte jo eksempelvis både "Microsoft", "Bill Gates" og "ledelsen af en multinational koncern". At du med dette også skulle mene IBM var ikke for mig klart.

Det glæder mig dog, at du også er interesseret i at begrænse eksempelvis IBMs indflydelse, så jeg håber da, at du i fremtiden vil nævne dem også, når du fabulerer omkring "multinationale koncerner".

  • 0
  • 0
#150 Anders Rosendal

Svaret på "implementerer jeg OOXML" skal findes i conformance-clauses i 29500. Der er to af dem (S og T), hvoraf Microsoft implementerer den ene.

Så 50%.

Så T er 5800 sider og S 200 sider.

Kan du forklare bedre hvor "stor" S og T er? Jeg forstod dig åbenbart ikke første gang.

Det har han jo ret i - men på et eller andet tidspunkt bør vi vælge at slå en streg i sandet. Her er Jens Hørlück og jeg jo meget enige. Jens mener blot, at vi skal slå stregen nu, jeg mener vi skal slå stregen, når S esisterer i markedet.

Hvis ikke du har et problem med tab når man konverterer gamle .doc, så burde ODF vel være fin?

  • 0
  • 0
#151 Jesper Lund Stocholm Blogger

Hej Anders,

Kan du forklare bedre hvor "stor" S og T er? Jeg forstod dig åbenbart ikke første gang.

Et simpelt billede på forskellen (men alligevel ikke helt retvisende pga dobbeltfunktionalitet) er, at "S dækker Part 1 og T dækker Part 1 og Part 4".

Jeg kan ikke huske det nøjagtige sidetal, men det kan du jo selv slå op.

Hvis ikke du har et problem med tab når man konverterer gamle .doc, så burde ODF vel være fin?

Vær opmærksom på, at jeg ikke er enig i Jaspers anke men enig i det faktuelle i, at der vil ske informationstab ved konvertering fra T til S.

Gamle DOC kan jo konverteres til OOXML-T - der er intet natur-givet i, at de skal kunne konverteres til OOXML-S.

Jeg kunne ikke finde på at tvinge informationstab ned over hovedet på folk ved at kræve, at de skulle konvertere deres dokumenter til S - ganske som jeg ikke kunne finde på at tvinge folk til informationstab ved at kræve, at man anvender ODF - fx eksempelvis Microsoft Office. Det må være folks eget valg. Hvis man ønsker at anvende ODF fra Microsoft Office, så for min skyld ingen alarm - men det skal være muligt at undgå det. Dette kan eksempelvis ske ved at anbefale "hele OOXML samt ODF" og ikke kun ODF og/eller OOXML-S.

  • 0
  • 0
#152 Ayhan Binici

Hej Jesper.

Som jeg hører Microsofts primære anke imod S, er den at man med S ikke kan sikre at ældre dokumenter (DOC, ECMA-376 1st ed) kan overføres uden tab til det åbne xml-baserede OOXML-format.

Jeg som gik rundt og troede at Microsoft havde nogle af verdens bedste udviklere ansat. Det kan betyde ét af følgende udsagn:

  1. At MS' udviklere er ikke kompetente nok til at implementere et stykke software der kan foretage en konvertering fra det ene format til det andet.
  2. At ikke engang MS' udviklere kan finde rundt i deres legacy-tyngede formater.
  3. At OOXML-S desværre er et format der ikke er godt nok til formålet.
  4. Eller at MS' har en hemmelig agenda med kun at implementere OOXML-T.

Hvilken gætter du er mest sandsynlig?

  • 0
  • 0
#153 Vijay Prasad

Jeg kunne ikke finde på at tvinge informationstab ned over hovedet på folk ved at kræve, at de skulle konvertere deres dokumenter til S

Jeg har vist skrevet om det før, men, igen: 1) lige meget hvad man vælger, kan man ikke undgå "informationstab"; 2) "informationstab" er et diffust begreb, som ikke kan faktualiseres uden en kontekst.

  • 0
  • 0
#154 Carsten Sonne

Hej Jesper,

[b] Selv hvis en standard var at regne som Guds eenborne søn og i sig selv var perfekt, ren, tysk og hvid, så er det i forbindelse med en politisk anbefaling naturligvis en faktor, hvis anvendelsen af den giver problemer for bare 50% af brugerne, der skal bruge den. Det kan og bør naturligvis påvirke en beslutning af, om det nu giver mening at bruge den konkrete standard som eneste mulighed. [/b]

Lad mig i flæng nævne standarder der kan regnes som ”Guds eenborne søn”.

SMTP, FTP, HTTP

ATM, ISDN. ADSL

GSM, EDGE, HSDPA, SMS

FM, PAL, DVB-T, DVB-S

ASCII, Unicode

MPEG, JPEG, PDF/X

ISA, PCI, AGP

RS-232, RS-485

C (ISO/IEC 9899)

Eller det måske ultimativt eksempel: TCP og IP

At ”50 %” af brugerne skulle opleve problemer, er jo blot tankespin. Det er en vurdering fra en part i sagen, der ikke kan sandsynliggøres uden at indgå på flaske præmisser.

Det er simpelthen for tyndt en argumentation for at give køb på det eneste en standard egentlig kan, nemlig at sikre interoperabilitet.

[b]Som standard er OOXML fuldstændig værdiløs. Det er et redskab der kan bruges i ”politisk” øjemed, INTET andet.[/b]

God Jul.

Mvh Carsten Sonne Larsen

  • 0
  • 0
#156 Anders Rosendal

At du tager fejl i alle 4 punkter (tro det eller lad være).

Du har før skrevet du ikke kan udtale dig om hvad der sker indenfor ms. Hvad gør du pludselig har skiftet mening og blankt kan afvise alle 4 punkter? Er du blevet ansat af microsoft?

Og hvis du pludselig ved vhad der sker indenfor ms, så svar lige på hvornår ooxml-s er færdig.

Takker.

  • 0
  • 0
#157 Jesper Lund Stocholm Blogger

Hej Anders,

Du har før skrevet du ikke kan udtale dig om hvad der sker indenfor ms.

Det er korrekt - men til gengæld er jeg overordentligt kvalificeret til at udtale mig om OOXML ... i modsætning til (host) nogle andre ...

Derfor kan jeg med al mulig autoritet sige, at det ikke er muligt at lave en tabfri konvertering af hele T til S.

For Microsoft er dette et problem, for de får ticks, når man taler om, at man vil indføre inkompatibilitet imellem forskellige versioner af samme format (dyre lærepenge fra da de lavede så meget om i dokumentformaterne fra Office 95 til Office 97, at deres kunder ikke kunne håndtere det). Det behøver jeg ikke være ansat i MS for at vide - eller på nogen måde være særligt knyttet til dem. Jeg kan blot læse, hvad Jasper har skrevet på sin egen blog eller i et af hans utallige svar til Jens Hørlück på [i]hans[/i] blog, hvor han redefør for, hvorfor S ikke er en god idé.

(og den opmærksomme læser vil vide, at hans argumenter er markant anderledes end mine for hvorfor S ikke er en skide god idé - endnu)

  • 0
  • 0
#158 Jesper Lund Stocholm Blogger

Hej Carsten,

Nu kender jeg ikke alle de standarder du nævner i detaljer, men det springer i øjnene, at du nævner både ASCII og Unicode som "eenborne sønner".

For ASCII er jo et tegnsæt (encoding), der er veldefineret og velfungerende ... altså hvis man er engelsktalende og bevæger sig stringent indenfor sig det af engelsk begrænsede økosystem - vel 400 millioner af verdens 6.8 mia beboere. I det øjeblik man forsøger at udveksle data med de udenfor økosystemet, der eventuelt har andre brugsmønstre, sprog etc end de af ASCII dækkede, så løber man ind i ... øeh ... "udfordringer".

Man har så lavet et noget bredere dækkende system, der stort set dækker alt og alle. Der er nok ikke nogen, der har brug for alle tegn i UNICODE på én gang i daglig brug, men det kan dække alles brug.

Der er så sikkert nogen i USA, der vil sige, at vores danske brug af "ø" (incl. Norge er der vel 10 millioner, der bruger dette bogstav) ikke på nogen måde retfærdiggør brugen af sådan en kompliceret størrelse som UNICODE og at man så bare må lade være med at bruge dette bogstav. Ja, 10 millioner svarer jo kun til 2.5% af brugerne af ASCII og diminutive 0,15% af verdens befolkning, så tough luck - det er bare ærgeligt.

:o)

Nogen, der kan se parallellerne?

Et land som netop Norge, der jo ellers herinde er blevet udråbt til helte ifbm valg af ODF (faktisk kan jeg huske én, der proklamerede, at han ville flytte til Norge) og indtil videre ikke OOXML, har jo faktisk valgt, at alle data skal publiceres i UTF-8 ... og ikke i "det oplagte subsæt" ASCII eller ISO 8859, for den sags skyld.

Carsten, jeg har faktisk ikke før nu tænkt på ASCII og UNICODE som eksempler på "to standarder med samme mål/overlap", så tak fordi du gjorde mig opmærksom på det - den er nu skrevet på listen sammen med alle de andre eksempler.

  • 0
  • 0
#159 Deleted User

Carsten, jeg har faktisk ikke før nu tænkt på ASCII og UNICODE som eksempler på "to standarder med samme mål/overlap", så tak fordi du gjorde mig opmærksom på det - den er nu skrevet på listen sammen med alle de andre eksempler.

Heldigvis er de dårlige eksempler. Eksempler på problemerne som opstår når der er mere end 1 standard.

  • 0
  • 0
#160 Jesper Lund Stocholm Blogger

Hej Jon,

Heldigvis er de dårlige eksempler. Eksempler på problemerne som opstår når der er mere end 1 standard.

Det er dejligt at se, at du ikke så nogen grund til at påpege dette, da argumentet var [b]imod[/b] OOXML (dobbelt-format-beslutning) men i samme øjeblik jeg vendte det om, så fandt du det betimeligt at påpege, at det jo forresten var et dårligt eksempel.

Hvad er det man kalder sådan noget?

:o)

  • 0
  • 0
#163 Anders Rosendal

jesper: Du tager fejl. Faktisk er dit indlæg så rodet jeg ikke forstår hvor du vil hen. Ascii er åbenbart dårligt. Og Norge burde have valgt ascii synes du, men de valgte ikke "det oplagte subsæt".

Du forstår åbenbart ikke hvorfor man laver en standard. Ascii behøver ikke indeholde samtlige tegn. Dette er IKKE ideen, hensigten, målet eller hvad du ellers har tryllet frem i dit hoved. Ascii indeholder nogle tegn og en måde at repræsentere dem på. Og når jeg snakker om ascii og andre læser det, ved vi PRÆCIS hvad det indebærer.

Norge gjorde NETOP noget smart. De valgte en rigtig åben standard og ikke ooxml-t som indeholder mulighed for udvidelser og andre "overraskelser" fra microsoft. Derudover har de ikke defineret deres eget tegnsæt. Men igen valgt en standard.

  • 0
  • 0
#164 Jesper Lund Stocholm Blogger

Hej Anders,

Ascii er åbenbart dårligt. Og Norge burde have valgt ascii synes du, men de valgte ikke "det oplagte subsæt".

ASCII er bestemt ikke dårligt - det er blot så begrænset, at det ikke kan stå alene.

... og det var faktisk et udtryk for sarkasme, at jeg nævnte "det oplagte subsæt" - men jeg skal for fremtiden hjælpe dig ved at gøre mere tydeligt opmærksom på de situationer, hvor jeg bruger sarkasme.

Ascii behøver ikke indeholde samtlige tegn. Dette er IKKE ideen, hensigten, målet eller hvad du ellers har tryllet frem i dit hoved. Ascii indeholder nogle tegn og en måde at repræsentere dem på. Og når jeg snakker om ascii og andre læser det, ved vi PRÆCIS hvad det indebærer.

Jeps - men synes du dermed, at når nu alle ovenstående er opfyldt - så er ASCII godt nok som valg af "eneste standard/encoding"? Ville det give mening i Danmark at anbefale, at al tekstuel kommunikation skulle foregå "via" ACSII og ikke "UTF-8", som man har valgt i Norge?

De valgte en rigtig åben standard og ikke ooxml-t som indeholder mulighed for udvidelser og andre "overraskelser" fra microsoft.

Jamen dog - og her troede jeg faktisk, at også ODF indeholdt "mulighed for udvidelser" - ja, jeg er faktisk helt sikker på, at folkene bag Gnumeric også tror det, da de bruger udvidelsesmulighederne i ODF til at putte deres egne ting ind.

Skal jeg tolke dit udsagn derhen, at når nu også ODF giver "mulighed for udvidelser", så er det ikke "en rigtig åben standard"?

... eller formulerede du dig igen lidt uheldigt?

  • 0
  • 0
#165 Deleted User

Jamen dog - og her troede jeg faktisk, at også ODF indeholdt "mulighed for udvidelser" - ja, jeg er faktisk helt sikker på, at folkene bag Gnumeric også tror det, da de bruger udvidelsesmulighederne i ODF til at putte deres egne ting ind.

Skal jeg tolke dit udsagn derhen, at når nu også ODF giver "mulighed for udvidelser", så er det ikke "en rigtig åben standard"?

... eller formulerede du dig igen lidt uheldigt?

Nej, det er bare dig som vrider og vender betydningen af ordene.

Anders formulerede det korrekt. Det er velkendt at Microsoft følger de 3 E'er. Embrace, Extend, Extinguish. Og det er et problem. Hvis nu bare Microsoft ville følge spillereglerne i stedet for at opfinde deres egne, så ville det hele gå meget bedre.

  • 0
  • 0
#167 Jesper Lund Stocholm Blogger

Hej Jon,

Det er super sødt, at I forsvarer hinanden, men

Anders skrev jo:

De valgte en rigtig åben standard og ikke ooxml-t som indeholder mulighed for udvidelser og andre "overraskelser" fra microsoft.

Så jeg spørger igen - ovenstående giver ODF ikke mulighed for?

  • 0
  • 0
Log ind eller Opret konto for at kommentere