Jesper Lund Stocholm bloghoved

ODF 1.2 i ISO (PAS submission)

Den anden dag landede et document på mit “bord” i Dansk Standard-gruppen for dokumentformater. Det var dokumentet ” EXPLANATORY REPORT - OASIS Submission of OpenDocument v1.2 to ISO/IEC JTC 1 [JTC1 N12033]”. Med andre ord: ODF TC i OASIS har ønsket at “forhøje” OASIS ODF 1.2 til en ISO-standard.

OASIS er en såkaldt ”PAS Submitter” i ISO, hvilket giver mulighed for mere eller mindre direkte ”ophøjelse” af eksisterende standarder som en ISO-standard, men uden (reel) medfølgende arbejde på selve standarden i ISO. OASIS ODF TC har brugt denne indgang til ISO for alle tidligere versioner af ODF, dvs fra den oprindelige ODF 1.0 til seneste version 1.1 inklusive rettelsesblade etc.

ODF bliver altså ikke vedligeholdt i ISO – man har aftalt, at selve arbejdet med at udvikle og forbedre ODF foregår i OASIS ODF TC, og så sendes den med jævne mellemrum til ISO for godkendelse – det nogen kalder ”rubber-stamping”.

For OOXMLs vedkommende lavede man en anden aftale efter indsendelse til ISO, nemlig at arbejdet med OOXML foregår i selve ISO og at det er hér, at standarden udvikles og forbedres. Når det så er sagt, så sker der relativt meget arbejde med OOXML i ECMA, og en stor del af vores arbejde i ISO stammer oprindeligt fra arbejdsgruppen for ECMA-376 – gruppen i ECMA, hvor OOXML blev ”født”.
ODF 1.2 blev godkendt i OASIS i september 2011 (og offentliggjort i januar 212), og nu næsten 3 år senere er den så landet på vores bord i ISO.

Jeg skrev straks til Dansk Standard og fortalte, at jeg foreslog, at vi stemte ”Ja” (teknisk set er dette ikke en opgave for udvalget for dokumentstandarder i Dansk Standard, da det er en JTC1-afstemning og vi kun arbejder med dokumenter på undergruppe-niveau i SC34), men jo mere jeg tænker over det, jo mere bliver jeg i tvivl, om hvorvidt ”Ja” er det rigtige.

For giver det overhovedet nogen værdi for nogen – tre år efter godkendelse i OASIS – at bede om et ISO-stempel? Er der nogen grund til at spilde ressourcer i ikke alene OASIS på dette, men også i ISO?

Og er spørgsmålet reelt ikke, om vi ikke er kommet dertil, hvor ODF har ”sejret ad helvede til” og er blevet irrelevant? Når nu det egentlige formål med ODF – at presse Microsoft til at underlægge dokumentformatet for Microsoft Office til international standardisering – er opfyldt, er det så ikke tid til at komme videre og bruge tiden mere nyttigt end at udvikle et dokumentformat, som ingen alligevel bruger?

Kommentarer (137)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Anders Lind

Og er spørgsmålet reelt ikke, om vi ikke er kommet dertil, hvor ODF har ”sejret ad helvede til” og er blevet irrelevant? Når nu det egentlige formål med ODF – at presse Microsoft til at underlægge dokumentformatet for Microsoft Office til international standardisering – er opfyldt, er det så ikke tid til at komme videre og bruge tiden mere nyttigt end at udvikle et dokumentformat, som ingen alligevel bruger?

Jeg bruger LibreOffice til dagligt, og jeg bruger derfor ODF.
Jeg har indtrykket af (men ingen tal på dette), at flere begynder at bruge OpenOffice og LibreOffice. Fx biblioteker - fx i Aarhus samt skoler og folk i privaten.

Man kan vel argumentere for, at hvis der er et sundt standardiseringsudvalg omkring ODF i OASIS, og internationale standarder endelig vedtages i ISO, så er der vel ikke noget problem i det. Det svarer vel lidt til, at vi har vores gode dronning, der skriver under på vores love, som folketinget har udformet, bortset fra at ISO har mulighed for at komme med indvindinger, hvis de vil, eller at EU kan komme med kommentarer til folketinget, hvis vi er ved at bryde internationale love eller standarder - bare for analogiens skyld.

Gør det så ondt, at der er flere dokumentformater, ligesom der er flere formater for andre ting i denne verden?
Jeg synes det ikke.

  • 23
  • 1
Finn Christensen

Og er spørgsmålet reelt ikke, om vi ikke er kommet dertil, hvor ODF har sejret ad helvede til og er blevet irrelevant?

Netop derfor Jesper - hvis du sover på posten, så havner vi i det gamle rod igen. Ingen grund til at friste svage sjæle ;)

Jeg selv samt andre jeg kender bruger ODF i dag..

Selv mine gamle DOC filer, der bliver åbnet eller genanvendt bliver konverteret til ODF i samme forbindelse.

Windoze-platformen er ikke en hellig ko mere - den er under nye vinde nu og fremover, og derfor er det godt vi har ODF.

  • 19
  • 1
Eskild Nielsen

Hvis det tager 3 år at komme fra et vedtaget OASIS dokument til et dokument i ISO JTC1's indbakke, så er det processen der er blevet irrelevant.

Fejlen kan ligge hos OASIS, ISO eller 3.part, men det ændrer intet.

  • 9
  • 0
Tommy Vestermark

Når nu det egentlige formål med ODF – at presse Microsoft til at underlægge dokumentformatet for Microsoft Office til international standardisering...

Undskyld, men der må være noget, du har misforstået. Formålet med ODF er:

The purpose of this TC is to create an open, XML-based file format specification for office applications.

(Citeret fra OASIS. Fremhævningen af s'et er min).

Formålet med Office Open XML var vel oprindeligt at lave noget primært Microsoft Office kunne arbejde med samt at give Microsofts håndlangere et argument for at modarbejde ODF. Om det lykkes standardiseringsorganerne reelt at gøre OOXML mere bredt anvendeligt mangler vi vist stadig at se. Er Microsoft overhovedet selv begyndt at bruge OOXML i sin standardiserede form?

  • 21
  • 0
Jesper Lund Stocholm

Jeg bliver helt i tvivl om jeg som bruger af ODF skal føle mig repræsenteret af dig i Dansk Standard.


OASIS ODF TC har fra starten insisteret på, at alt arbejde med ODF blev foretaget i OASIS. Udvalget for dokumentformater i DS (som jeg er formand for) er et spejl-udvalg af JTC1 SC34 og har derfor ikke kunnet bidrage til ODF igennem de officielle kanaler. Vi havde i arbejdsgruppe 5 en repræsentant fra det danske udvalg (IBM), men det er rigtigt længe siden, at der er sket noget som helst i den gruppe - og IBM trak sig fra udvalget i DS for noget tid siden.

Vi har i udvalgets levetid (siden januar 2007, så vidt jeg husker), fået ét (1!) bidrag fra "danskerne" og dette blev behandlet i udvalget (vi var alle enige i, at det konkrete forslag ikke var en god idé, men vi behandlede det alligevel).

Under tilblivelsen af ODF 1.2, var Søren Roug nok den (aller)mest aktive dansker ifht arbejdet i ODF TC. Men udover ham, så finder du ikke nogen danskere, der konkret har bidraget lige så meget til ODF som jeg har. Jeg blev endda nævnt med navns nævnelse af Rob Weir i hans "takketale", da ODF 1.2 blev godkendt i OASIS tilbage i 2011. Så vidt jeg husker, er der endda tekst i ODF 1.2, der er mine ord i kraft at nogle af de forslag jeg kom med undervejs.

Din kommentar er i bedste fald uoplyst.

  • 4
  • 4
Jesper Lund Stocholm

Formålet med Office Open XML var vel oprindeligt at lave noget primært Microsoft Office kunne arbejde


Formålet med standardisering af OOXML står i ISO-standarden:

*ISO/IEC 29500 defines a set of XML vocabularies for representing word-processing documents, spreadsheets and presentations. On the one hand, the goal of ISO/IEC 29500 is to be capable of faithfully representing the pre- existing corpus of word-processing documents, spreadsheets and presentations that had been produced by the Microsoft Office applications (from Microsoft Office 97 to Microsoft Office 2008, inclusive) at the date of the creation of ISO/IEC 29500. It also specifies requirements for Office Open XML consumers and producers. On the other hand, the goal is to facilitate extensibility and interoperability by enabling implementations by multiple vendors and on multiple platforms. *

Så formålet med OOXML var at standardisere dokumentformatet i Microsoft Office. Derudover var der et meget konkret politisk ønske om at fravriste Microsoft den suværene kontrol med dokumentformatet og give de nationale råd i ISO mulighed for at påvirke processen.

Er Microsoft overhovedet selv begyndt at bruge OOXML i sin standardiserede form?


Er det et retorisk spørgsmål, eller har du eksempler på, at dokumenterne dannet af Microsoft Office ikke overholder kravene i OOXML?

  • 5
  • 1
Jesper Lund Stocholm

Hvis det tager 3 år at komme fra et vedtaget OASIS dokument til et dokument i ISO JTC1's indbakke, så er det processen der er blevet irrelevant.


Uanset årsagen, så er det ganske rimeligt at stille spørgsmålstegn ved værdien af at ophøje ODF 1.2 til en ISO-standard her tre år efter.

Jeg spurgte nogle af mine kolleger i arbejdsgruppen for OOXML (de sidder også i ODF TC) om deres tanker, og nogle af dem anførte, at der jo var nogen organisationer/lande, der ikke kan acceptere andet end ISO-standarder.

Men hvilken værdi giver det for dem, at ODF 1.2 har taget tre år at indsende til ISO? Og tror nogen virkeligt, at der er nogen, der har afvist at opgradere deres installation af fx LibreOffice til en version, der bruger ODF 1.2 ,af den grund at ODF 1.2 ikke er en ISO-standard endnu?

  • 2
  • 1
Jesper Lund Stocholm

Gør det så ondt, at der er flere dokumentformater, ligesom der er flere formater for andre ting i denne verden?


Nu er det efterhånden 10 timer siden du postede din kommentar, og jeg ville nu have forventet en syndflod af kommentarer omkring, hvordan verden ville ophøre med at dreje rundt, hvis der var to bredder af togspor i verden, to slags gevind til møtrikker, to slags elpærer, to slags <indsæt selv absurditet her> ... men det er tydeligvist ikke sket.

... folk er nok blevet klogere.

Jeg har sådan set ikke noget imod, at ODF 1.2 bliver en ISO-standard. Men det skal selvfølgelig kun ske, hvis det skaber værdi. Jeg kunne sagtens se en værdi i det, hvis ODF 1.2 var blevet indsendt til ISO efter offentliggørelsen i starten af 2012. Men hvilken værdi skaber det at indsende den nu? Den bliver tidligst godkendt i slutningen af 2014 og først offentliggjort i første halvdel af 2015.

Rob Weir har selv understreget, at grunden til forsinkelsen er mangel på ressourcer i ODF TC. Hvis ISO-godkendelse er af så lav prioritet for ODF TC, at man ikke kan afsætte ressourcerne til det - hvor er så værdien?

  • 1
  • 5
Palle Simonsen

Har lige brugt 1,5 time på at flette rettelser modtaget i OOXML format tilbage i et OOXML worddokument.

Scenarie:
1. Udarbejde original dokument i gennemprøvet Word 2010, OOXML skabelon
2. Sende originaldokument til supplement hos samarbejdspartnere
3. Modtage tilføjelser fra Word 2013 i OOXML - formatering vælter, overskrifter og figurhenvisninger stopper med at virke.
4. Modtage reviewkommentarer fra Mac Word 2011 i OOXML format. Igen formateringsproblemer.

Så Kære Jesper og I andre. Kunne I ikke også koncentrerer jer om at få de faktiske OOXML implementeringer til at overholde den samme version af OOXML?

  • 4
  • 1
Jesper Lund Stocholm

Så Kære Jesper og I andre. Kunne I ikke også koncentrerer jer om at få de faktiske OOXML implementeringer til at overholde den samme version af OOXML?


Det er udenfor standardiseringsgrupperne arbejdsområde (vi kan ikke tvinge producenterne til noget). Hvis du ikke er tilfreds med funktionaliteten i en kontorpakke, så må du stemme med fødderne og bruge en anden.

  • 3
  • 1
Nikolaj Brinch Jørgensen

Nu køber de fleste produkter og ikke underliggende filformater.
Indtil OpenOffice/LibreOffice viser sig konkurrencedygtig overfor Microsoft Office, så er diskussionen ikke specielt relevant.
Jeg prøvede selv i 1,5 år at benytte OpenOffice/LibreOffice, men valgte tilsidst at punge den beskedne sum ud det koster at erhverve sig Microsoft Office. Taget i betragtning den højnede produktivitet, så har der for mig været en stor besparelse i at benytte Word, Excel etc. i forhold til tidligere med OO/LO.

Hvad angår dokumentkompatibilitet har jeg endnu til gode at opdage noget jeg ikke kan åbne i MSO der bare virker, hvor dette bestemt ikke var tilfældet i OO/LO. Det var nærmere reglen end undtagelsen at dokumenter opførte sig "skævt" når de blev åbnet i OO/LO.

Med den markedsandel MSO har, så ligger opgaven altså hos OO/LO, og ikke omvendt.

Godt arbejde Jesper!

  • 0
  • 8
Jesper Lund Stocholm

Jeg prøvede selv i 1,5 år at benytte OpenOffice/LibreOffice, men valgte tilsidst at punge den beskedne sum ud det koster at erhverve sig Microsoft Office. Taget i betragtning den højnede produktivitet, så har der for mig været en stor besparelse i at benytte Word, Excel etc. i forhold til tidligere med OO/LO.


Man skal altid huske på, at oplevelser som dine er meget afhængige af, hvilket økosystem man er i. Der er ret store netværkseffekter forbundet med brugen af en kontorpakke, så hvis ens netværk bruger primært OO/LO, så vil oplevelsen sikkert være god (og omvendt med MSO).

Jeg gør selv jævnligt som du gør - nemlig skifter MSO ud med OO/LO - for at se, om det giver mening for mig (produktivitetsmæssigt). Der er jo ingen grund til at sende penge til Redmond, hvis det ikke er nødvendigt. Men der går typisk ikke særligt lang tid, før jeg skifter tilbage igen. Oplevelsen for mig med brug af OO/LO er ganske enkelt ikke god nok.

Dette skyldes ganske sikkert, at størstedelen af dem jeg kender og arbejder med bruger en eller anden udgave af MSO, men det ændrer ikke på, at det, for mig som bruger af en kontorpakke, er ret svært at skifte til OO/LO som primær kontorpakke.

  • 2
  • 2
Jesper Lund Stocholm

Så MSO må gerne modarbejde OO/LO hvis de vil?


Gør de det? Microsoft har investeret ikke-ubetydelige ressourcer i arbejdet med ODF i både Microsoft Office selv og i ODF TC (digitale signaturer, change-tracking - for blot at nævne to af de større områder i ODF, hvor de har bidraget substantielt), og det er en stor hjælp for os i det daglige arbejde med OOXML, at repræsentanterne fra Microsoft i gruppen også arbejder med ODF i det daglige.

  • 1
  • 4
Nikolaj Brinch Jørgensen

Så MSO må gerne modarbejde OO/LO hvis de vil?

Jeg er ikke sikker på hvor du lige får den påstand fra? Det mener jeg ikke at have skrevet?

Hvis du laver en ny CAD pakke, så ligger opgaven vist hos dig at være kompatibel med Autodesk produkter og SketchUp, de har da i hvert fald ikke tænkt sig at bekymre sig det mindste om dit produkt. Det samme gælder vel for MSO vs OO/LO.

  • 0
  • 3
Palle Simonsen

Det er udenfor standardiseringsgrupperne arbejdsområde (vi kan ikke tvinge producenterne til noget). Hvis du ikke er tilfreds med funktionaliteten i en kontorpakke, så må du stemme med fødderne og bruge en anden

Jesper, jeg synes at dette og andre lignende eksempler viser at jeres arbejde er værdiløst.

Hvis standarden ikke overholdes af forskellige produkter fra samme producent, som overn i købet står bag standarden og vel er den eneste der implementere den, kan jeg ikke se, hvad jeres såkaldte "standardiseringsarbejde" kan bruges til.

Beklager, men jeg bliver ganske pikeret over at blive affærdiget om en skoledreng med en så letkøbt argumentation.

Venligst

  • 7
  • 1
Nikolaj Brinch Jørgensen

Jeg gør selv jævnligt som du gør - nemlig skifter MSO ud med OO/LO - for at se, om det giver mening for mig (produktivitetsmæssigt). Der er jo ingen grund til at sende penge til Redmond, hvis det ikke er nødvendigt.

Præcis! Jeg benytter i mit arbejde flere forskellige IDE'er (Eclipse, Netbeans, IntelliJ). Det er klart at for Grails arbejde er IntelliJ lige nu bedre end Eclipse (Netbeans 8 er kommet ret godt med). Det er også klart at på det tidspunkt hvor IntelliJ ikke tilbyder noget som er relevant og mere produktivitetsfremmende, så ryger den, så jeg slipper for at betale for det.

Det undrer mig så faktisk at der købes Oracles Java produkter i et væk, da de jo ikke tilbyder andet end meromkostninger og nedsat produktivitet, samt ingen eller meget ringe support?
Tilmed er der jo kun meget få virksomheder/myndigheder i DK der har brug for Oracle RDBMS, hvis nogen overhovedet. Altså DK og BigData, come on... :-)

  • 2
  • 2
Jesper Lund Stocholm

Det samme gælder vel for MSO vs OO/LO.


Jeg fik engang lov til at se en liste over features i Microsoft Office's implementering af ODF 1.1, hvor man havde været nødt til at håndtere quirks i OOs implementering af ODF, hvor OO ikke overholdt standarden.

Selvfølgelig betyder interoperabilitet noget. Implementering af en hvilkensomhelst suite er jo ikke en clean-room implementering, hvor man sætter sig ind i et lukket rum - med en computer og standarden, man skal implementere. Naturligvis er man nødt til at forholde sig til, hvordan substantielle spillere opfører sig på markedet. Dette er tilfældet med MSO -> ODF og OO/LO -> OOXML.

Der, hvor kæden falder af for mig er, når man begynder at rette (uberettiget) skyld og motivspekulation imod nogen for at noget ikke virker optimalt.

  • 2
  • 3
Jesper Lund Stocholm

Hvis standarden ikke overholdes af forskellige produkter fra samme producent, som overn i købet står bag standarden og vel er den eneste der implementere den, kan jeg ikke se, hvad jeres såkaldte "standardiseringsarbejde" kan bruges til.


Men det er jo netop dilemmaet med standardisering i en nøddeskal. Vi kan ikke tvinge nogen til noget. Vi kan gøre vores bedste for at standarden er klart formuleret og danner et nogenlunde fornuftigt grundlag for interoperabilitet. Men vi kan ikke tvinge nogen. Tvang er for myndigheder.

Beklager, men jeg bliver ganske pikeret over at blive affærdiget om en skoledreng med en så letkøbt argumentation.


Det var ikke min mening - men der er ikke noget bedre svar end "det kan vi ikke".

Jeg giver i øvrigt ikke meget for argumentet om, at Microsoft er den eneste, der kan implementere OOXML :-).

  • 3
  • 1
Mogens Hansen

Og er spørgsmålet reelt ikke, om vi ikke er kommet dertil, hvor ODF har ”sejret ad helvede til” og er blevet irrelevant? Når nu det egentlige formål med ODF – at presse Microsoft til at underlægge dokumentformatet for Microsoft Office til international standardisering – er opfyldt, er det så ikke tid til at komme videre og bruge tiden mere nyttigt end at udvikle et dokumentformat, som ingen alligevel bruger?

Der er et ordsprog om at lære af historien. I historien har vi masser af eksempler på at MS været rigtig gode til at være søde community-borgere, lige indtil det tidspunkt hvor de har opnået et de-facto monopol, hvorefter de vender ryggen til det hele og går deres egne veje.
Derfor er det vigtigt, at der opretholdes et pres på åbenheden.
Og derfor er det vigtigt, at du stemte ja til beslutningen. Det var et godt valg du foretog.

  • 5
  • 0
Jesper Lund Stocholm

Er der ikke en certificeringsuite eller andet, som en producent skal bestå, før man kan averterer sit produkt, som værende compliant med standarden?


Hmmm ... der er sådan set to svar på dette:

  1. Nej, der findes ikke sådan en liste. Man har både i ODF- og OOXML-sammenhænge snakket om dette flere gange, men det er blevet ved snakken. Problemet er reelt, at det er en kæmpe opgave og at der ikke er nogen, der vil afsætte ressourcerne til dette. Microsoft har en samling af vist 10000 ODF-dokumenter, som de brugte til deres ODF-implementering i MSO, og jeg mener, at disse er blevet offentligt tilgængelige ifbm en ODF Plug-fest for et par år siden, men nogen "officiel" certificerings-liste findes ikke.

  2. Jeg er reelt i tvivl om, hvorvidt dette vil bringe værdi til økosystemet. For en implementør står interoperabilitet næsten lige så højt som at overholde selve standarden. Står Microsoft eksempelvis i en situation, at ODF kræver et eller andet og OO/LO ikke håndterer dette korrekt, så vil de sandsynligvis vælge at følge opførslen i OO/LO - selvom det betyder, at de ikke vil overholde standarden på dette punkt.

Selvom man valgte at kaste ressourcerne efter sådan en test, så tror jeg reelt ikke, at nogen implementeringer vil kunne komme ud med udelukkende "OK-markeringer".

  • 2
  • 0
Keld Simonsen

Det er nødvendigt at ODF er en ISO standard, for at forskellige nationer kan anføre den som åben standard i deres standardporteføljer.
ODF var hovedstandarden da folketinget vedtog B103/2006 omkring åbne standarder i staten og i det offentlige.

Der har så været mindre arbejdsstyrke bag ODF end bag OOXML i ISO-standardiseringsarbejdet. Nok fordi Microsoft har flere penge end SUN og Oracle og IBM, og fordi der var flere penge på spil for Microsoft. Og så nok også fordi folk i OASIS ikke har gennemskuet værdien af ISO-standardisering for ODF's succes. Bl.a. fordi strategien med ISO-standardiseringen ikke var udtænkt i OASIS. Så OASIS har holdt standardiseringen inden for egne rækker. Og ikke givet så mange ressourcer til ISO-standardiseringen. Nok fordi nogen i OASIS mener at ISO er uinteressant, det er jo kun de amerikanske standardiseringsorganisationer der er relevante.

Jeg har skubbet på i ISO omkring standardisering af ODF. Også ODF 1.2. Det var faktisk DKUUG der lavede strategien omkring standardisering af ODF i OASIS og ISO. Claus Sørensen (nu Agerskov) fik så OASIS til at lave ODF-standardiseringsprojektet, og jeg fik ISO til at lave fast-track. Og jeg påpegede problemerne overfor ISO og OASIS ved ikke at udvikle ODF-standarden i et samarbejde mellem OASIS og ISO, herunder forsinkelsen af ISO-standarden. Men det har været svært at trænge igennem. Og DKUUG er holdt op med at støtte arbejdet.

Men alt er ikke tabt. Det vil være rigtigt godt at få ISO-godkendt ODF 1.2. Microsoft og deres allierede har for nylig argumenteret over for folketinget at ODF ikke er moden, og det vil de nok have sværere ved, når ODF 1.2 bliver ISO-godkendt.

  • 9
  • 0
Tommy Vestermark

Så formålet med OOXML var at standardisere dokumentformatet i Microsoft Office. Derudover var der et meget konkret politisk ønske om at fravriste Microsoft den suværene kontrol med dokumentformatet og give de nationale råd i ISO mulighed for at påvirke processen.

Ja, Ja. ISOs formål er skam godt og ædelt. Jeg tvivler dog stærkt på, at det var Microsofts oprindelige formål med at standardisere, at de skulle fravristes den suveræne kontrol :-) Som du selv skriver, blev det vel katalyseret af ODF, som tvang Microsoft til at søge standardiseringens blå stempel for at kunne leve op til diverse myndigheders begyndende krav om åbne formater.

Er det et retorisk spørgsmål, eller har du eksempler på, at dokumenterne dannet af Microsoft Office ikke overholder kravene i OOXML?

Det er skam et ærligt spørgsmål, som jeg håbede, at du var i stand til at bringe lys over. Microsoft erklærede jo selv, at MS Office 2010 ikke fulgte standarden. Det er nok de færreste, der i praksis sidder og holder øje med, om de filer de gemmer reelt overholder standarden. Det er først, når man skal samarbejde med andre programmer, at problemerne opstår...

Det er min egen erfaring, at ODF i praksis er tættere på at være "interoperable" og "multiple platforms" end OOXML - men YMMV.

  • 9
  • 0
Eskild Nielsen

For mange år siden - før det var før det var før - skulle jeg forsøge i den daværende version af Word at samle dokumenter fra flere lande til et dokument - lidt fra hvert kilde - plus lidt fra mig selv.

Alt skrevet i de nationale versioner af den dengang seneste Word.

Det tog et par timer at klippe dokumenterne sammen
Det tog mange dage at få det samlede dokument til at kunne udskrives korrekt på en gang.

  • 7
  • 0
Jesper Lund Stocholm

Ja, Ja. ISOs formål er skam godt og ædelt. Jeg tvivler dog stærkt på, at det var Microsofts oprindelige formål med at standardisere, at de skulle fravristes den suveræne kontrol :-)


Det var faktisk heller ikke den oprindelige mening. Min egen hukommelse og vurdering er, at man pludseligt i ISO og i de enkelte lande indså, hvor meget det betød for Microsoft at få OOXML godkendt i ISO, og derfor krævede man tillige, at vedligeholdelse skulle ske i ISO. Jeg er helt overbevist om, at - på det tidspunkt - Microsoft helst havde bibeholdt vedligehold og udvikling af OOXML i ECMA. På den måde var det som enhver anden forhandling, hvor man pludseligt indser, at man kan få noget billigere/bedre/større etc, da man opdager en "svaghed" hos modparten.

Næsten hver gang vi mødes i arbejdsgruppen snakker vi uformelt omkring værdiskabelsen af at vedligeholde OOXML i ISO, og det er min klare opfattelse, at selv Microsoft i dag synes, at det er en god idé. De bruger naturligvis nogle penge på at rejse rundt i verden til møder og bruger tid på telefonkonferencer, men de har fået en markant bedre standard ud af det - hvilket gør det nemmere at implementere Office. Jeg hører også (nogle gange imellem linierne), at alene det at de ikke har fuld råderet over standarden faktisk er meget nyttigt for dem ifht interne afklaringer om denne eller hin måde at implementere "funktion x" på. Der er ganske enkelt en masse diskussioner de ikke længere behøver at tage.

Microsoft erklærede jo selv, at MS Office 2010 ikke fulgte standarden.


Gjorde de?

  • 1
  • 2
Keld Simonsen

OOXML er kørt efter en anden procedure i ISO end ODF. OOXML er fast-track, hvor ODF er PAS. Procedurerne er næsten ens, men der kan være en lille forskel i måden at vedligeholde standarderne på. Oprindeligt ville Ecma vedligeholde OOXML hos sig selv og via SC22, men jeg foreslog at den skulle vedligeholdes i fællesskab mellem ISO og Ecma og i SC34, ligesom POSIX-standarden bliver vedligeholdt af The Open group, IEEE og ISO. Det blev til at OOXML helt og aldeles skulle vedligeholdes af ISO.

Det viser nok bare at Ecma/Microsoft har en bedre næse for strategi end OASIS.

  • 3
  • 0
Peter Stricker

Eksisterer der så i dag officepakker, der overholder hele OOXML?

Og med hele OOXML mener jeg både læsning og skrivning af både Strict og Transitional. Altså, at det ikke er en opfyldelse af Strict, at implementere parts 1-4, hvis man ikke kan udelade part 4.

Det er jo interessant, når du nu stiller spørgsmålstegn ved ODF's relevans, om der i det hele taget eksisterer et ISO godkendt dokumentformat, der er relevant.

  • 2
  • 0
Jesper Lund Stocholm

Eksisterer der så i dag officepakker, der overholder hele OOXML?


Ja

Og med hele OOXML mener jeg både læsning og skrivning af både Strict og Transitional.


Office 2013 understøtter læsning og skrivning af både Strict og Transitional.

ltså, at det ikke er en opfyldelse af Strict, at implementere parts 1-4, hvis man ikke kan udelade part 4.


Husk lige på følgende:

Part 1 - strict - skal alle implementere
Part 2 - pakkeformatet - skal alle implementere
Part 3 - udvidelser - skal alle implementere
Part 4 - transitional - skal kun implementeres, hvis man ønsker at understøtte Transitional

  • 1
  • 0
Peter Stricker

Husk lige på følgende:

Part 1 - strict - skal alle implementere
Part 2 - pakkeformatet - skal alle implementere
Part 3 - udvidelser - skal alle implementere
Part 4 - transitional - skal kun implementeres, hvis man ønsker at understøtte Transitional


Er et dokument Strict, hvis det bruger elementer fra part 4?

Hvis nej, så skal din definition af Part 4 vel udvides med "og må ikke benyttes i et Strict dokument".

Jeg er helt med på, at en officepakke skal kunne behandle part 1-4 for at kunne dække hele OOXML, både Strict og Transitional.

Men samme officepakke skal vel også kunne garantere, ikke at medtage elementer fra part 4, for at kunne hævde at den kan producere Strict dokumenter?

  • 3
  • 0
Jesper Lund Stocholm
  • 3
  • 0
Jesper Lund Stocholm

Det lyder positivt i forhold til tidligere udmeldinger om, at fuld OOXML understøttelse måtte vente til Office 2015.


Faktisk var meldingen ikke "Office 2015" men "Office 15", og da Office 2013 også hedder "Office 15", så er den spot on :-)

Kender du status på andre officepakker?


Nej, ikke pt. - men man kunne jo forestille sig, at der var nogen (host!), der skrev et blogindlæg om det snarest :-).

  • 3
  • 0
Jesper Lund Stocholm

Markus Feilner skriver om dokumentformater (OOXML, ODF)


Øv!

Hvad gør man, når tredje sætning i dokumentet er

The later OOXML standard (ISO/IEC 29500), originally developed by a single proprietary software vendor, is implemented in three different versions (‘ECMA’, ‘Transitional’ and ‘Strict’) that are not compatible with each other.

... og ens hjerne går i "does-not-compute"-mode?

Står der overhovedet noget, der er enten korrekt eller fri for kvalmende bias?

  • 0
  • 5
Jørgen Henningsen

Man kan diskutere om ikke tiden er løbet fra office formaterne.

Hvis det ikke er noget jeg skal editerer i, så send mig en PDF, så kan jeg annoterer den og det kan vises korrekt på alle platforme.

Hvis jeg skal editerer i dokumentet, så del dokumentet med mig på google. Ellers skal vi alligevel ligge og slås med versionsstyring uanset hvilken absurd dokumentstandard man vælger.

Man skal også tænke på at vores lille andedam har altid været MS land, så i dit perspektiv har du nok ret i at en ODF standard har begrænset relevans.

  • 0
  • 1
Jesper Lund Stocholm

Hvis det ikke er noget jeg skal editerer i, så send mig en PDF, så kan jeg annoterer den og det kan vises korrekt på alle platforme.


Da alt dette startede, så blev der lavet en undersøgelse, der viste, at 90% af alle dokumenter, der blev rundsendt i det offentlige i Danmark, blot blev vist på en skærm (og altså ikke redigeret). Af disse 90% var omtrent samme mængde i et redigerbart dokumentformat og ikke i PDF.

Så uanset at jeg er enig med dig - i princippet, så er virkeligheden, at vi har brug for interop via redigerbare formater. Det er urealistisk at tro, at vi kan få folk til at bruge PDF.

Det er ikke det samme som at sige, at vi ikke skal prøve - men i de nærmeste år, er vi afhængige af de redigerbare formater.

  • 1
  • 1
Jesper Lund Stocholm

Den engelske regering har valgt ODF (og ikke OOXML) som standard for udveksling af dokumenter i offentlig regi i Storbritannien. Godt gået !!


Ja, der står bla. i artiklen du henviser til, at

Use of ODF-compliant software by tens of thousands of U.K. government workers will provide incentives to Microsoft to take greater pains to ensure that documents saved in ODF form will preserve their formatting with greater integrity

Det skal nok gå godt :-)

  • 0
  • 2
Bo Victor Thomsen

Det er da fløjtende ligegyldigt, hvilket program der benyttes til at generere data i; pointen er at data kan udveksles mellem programmer fra forskellige leverandører og programversioner uden at information går tabt eller at fortolkningen af data ændres. Hvis Microsoft ikke supporterer ODF 100% allerede, har de jo alle muligheder for at rette på den fadæse qua der foreligger en ISO standard - frisk fra fad !

  • 7
  • 1
Jesper Lund Stocholm

pointen er at data kan udveksles mellem programmer fra forskellige leverandører og programversioner uden at information går tabt eller at fortolkningen af data ændres.


Og hvad foreslår du så, at programmer som Microsoft Office, Apple iWorks eller andre gør ved deres funktionaliteter, der ikke kan persisteres i ODF?

Mener du virkeligt og ædrueligt, at et valg af kun ét muligt format løser dette problem?

  • 0
  • 1
Peter Stricker

Og hvad foreslår du så, at programmer som Microsoft Office, Apple iWorks eller andre gør ved deres funktionaliteter, der ikke kan persisteres i ODF?


Lade være med at tilbyde den delmængde af deres funktionalitet ved redigering af ODF dokumenter, selvfølgelig.

Hvordan har du ellers forestillet dig, at de skal håndtere ISO/IEC 29500 Strict?

  • 3
  • 0
Bo Victor Thomsen

Og hvad foreslår du så, at programmer som Microsoft Office, Apple iWorks eller andre gør ved deres funktionaliteter, der ikke kan persisteres i ODF?

Mener du virkeligt og ædrueligt, at et valg af kun ét muligt format løser dette problem?


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

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

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

  • 2
  • 0
Michael Rasmussen

Strict/Transitional handler primært om forskellige måder af beskrive en bestemt funktionalitet på - det drejer sig ikke nødvendigvis som forskellige funktionaliteter.

Det er vel ikke helt korrekt. Strict er mig bekendt et subset af Transitional, så funktionalitetsmæssigt kan man ikke 100% sætte lighedstegn mellem de 2.

  • 2
  • 0
Jesper Lund Stocholm

Nej, det løser ikke det - i min optik ganske minimale - problem


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

At kunne udveksle data mellem programmer fra forskellige leverandører.


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

At kunne udveksle data mellem programmer fra forskellige leverandører.


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

  • 1
  • 3
Bo Victor Thomsen

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


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

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


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

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


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

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

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

  • 5
  • 0
Jesper Lund Stocholm

At implementere 2 standarder, som har meget store overlap, til at løse 1 problem er ikke hensigtsmæssigt.


Og alligevel er det typisk sådan det foregår. I stort set alle andre områder med "indhold" har vi et væld af standarder, der er understøttet: tusinde billedformater, tusinde videoformater, 500 kompressionsformater etc. Hvor er værditabet her? Skulle man ønske det, findes der et utal af OSS-implementeringer som man kan bruge - hvis man ikke skulle ønske at implementere skidtet selv.

Hvorfor er det lige præcist et kæmpe problem, når vi taler om dokumentformater?

Og du indfører ekstra problemer, når du internt skal transformere data mellem de to formater.


Men det problem vil jo altid være der, og det går ikke væk, blot fordi man vælger ét format. Alene i ODF-miljøet er der allerede i dag et utal af implementeringer, der hver har brugt sine egne udvidelser til formatet, fordi selve ODF ikke kunne indfri ønskerne. Og når man man nu ønsker at vælge ODF (med englændernes agne ord, for at øge konkurrencen på området), så gør dette sig jo også gældende for selve dokumentformaterne. Konkurrencen kontorpakkerne imellem forsvinder jo, hvis deres featuresæt er defineret af en eller anden kommitte, der med nogle års mellemrum kommer med en ny version.

Det er et minimalt antal gange, hvor jeg har oplevet at det var nødvendigt at eksportere/importere office dokumenter med funktionalitet som ikke er understøttet af både ODF og OOXML.


Jeg kan regne ud, at du ikke har arbejdet med ændringsmarkering i hverken ODF eller OOXML eller prøvet på at få den ene til at matche den anden.

Men i det øjeblik, hvor dokumentet flyttes ud af virksomheden eller arkiveres, må man "begrænse" fuktionaliteten i dokumentet til hvad det valgte udvekslingsformat understøtter.


Og for "arkivering" har vi jo så udmærkede formater som PDF/A. Og den "begrænsede" idé du har må bero på en misforståelse. Man snakkede engang i ODF-regi om en "ODF Core", men selv dér kunne man ikke blive enige. Så vi er tilbage ved to dokumentformater - begge på tusindvis af siders beskrivelse. Og hvis du ser på uafhængige implementeringer af ODF og OOXML, så er der INTET, der tyder på, at det skulle være nemmere at implementere (den fulde) ODF end den fulde OOXML. De tests jeg har lavet i tidens løb (og offentliggjort herinde), viste faktisk, at der var bedre interop imellem uafhængige implementeringer af OOXML end for ODF.

og er et mere overskueligt format end OOXML


Du er simpelthen nødt til at sætte dig lidt mere ind i tingene end blot enten at fokusere snævert på egne erfaringer med implementeringer af import/eksport for en organisation eller læse på blogs på internettet. Kig derimod på ODFs bugtracker JIRA. Den er fuld af tusindvis af fejlrapporteringer, hvor der påpeges funktionalitet, der er umulig at implementere alene med standarden i hånden, funktionalitet, der er så vagt beskrevet, at den ikke kan implementeres eller direkte modsigende tekst i standarden.

Dine erfaringer med arbejde med ODF/OOXML ligner meget mine egne. Jeg har lavet masser af interop med import/eksport og generering af dokumenter i formaterne, og det er - uanset format - faktisk ret let. Men man er også nødt til at forholde sig til, at man i den situation kun berører en uhyre lille del af det samlede featuresæt i formaterne.

Jeg er sikker på, at du også har dit yndlingsformat ;-)


Nej, det har jeg faktisk ikke. Jeg har derimod erfaring siden 2007 med dybt, teknisk arbejde med selve dokumentformaterne og deres problematikker. Jeg har også gennemført en lang række tests (både her og internationalt) af interop imellem formaterne. Hvis du spørger nogen som helst (også på tomandshånd) af de, der arbejder med enten OOXML eller ODF i standardiserings-regi eller i produktregi (dvs fulde implementeringer som Microsoft Office, OpenOffice eller lignende), så vil INGEN nogensinde sige, at det er en god idé at oversætte det ene format til det andet. I ISO (SC34, arbejdsgruppe 5) blev en hel gruppe mennesker sat sammen til at arbejde med dette, men gode folk fra bogstaveligt talt hele verden) og efter 4 års arbejde måtte de erkende, at det er en umulig opgave.

Men det har tåberne i England åbenbart ikke hørt - eller også har de hørt efter de forkerte.

For nogle år siden formulerede jeg den kongstanke, at dokumenter skulle fødes, leve og dø i det format de blev oprettet i - uden konverteringer. Jeg mangler endnu at møde en person med kompetencerne til at vurdere udsagnet, der har været uenig.

Og inden du begynder at sige, at "Microsoft kan jo bare bruge ODF i Microsoft Office", så husk på, at et dokumentformat er en transformation af funktionaliteten i kontorpakken. Topografisk set er det stort set identiske. Så konsekvensen ved at droppe eget dokumentformat til fordel for ODF for andre kontorpakker end OpenOffice (og derivater) vil være, at de skal begynde at fjerne funktionalitet fra deres programmer.

Det kommer ikke til at ske.

  • 3
  • 5
Bo Victor Thomsen

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

(Med en lettere humoristisk tilgang)

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

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

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

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

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

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

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

For nu at sige det som det er:

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

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

  • 7
  • 0
Nikolaj Brinch Jørgensen

at der burde være en uvildig standard for dokumentudveksling og persistens.
Som der er det for f.eks. (X)HTML, vedligeholdt af W3C.

Dette er øjensynligt ikke muligt da MS allerede har fat i 90%+ (rent gæt) af markedet og derfor ikke har noget behov for at indgå i en sådan standardkommite. Men det ville være rart.

Når to eller flere udbydere af kontorpakker skal slås om hvilket af deres formater der skal være standard, så ender de alle med at blive standard, og markedet er vel ikke blevet rigere. Tværtimod er situationen uændret. Det ændrer jo intet at disse standarder er kommet på banen. Forbrugeren er ikke stillet anderledes end før.

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

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

  • 1
  • 2
Bo Victor Thomsen

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

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

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

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

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

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

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

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

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

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

  • 4
  • 0
Jesper Lund Stocholm

I dit oprindelige blogindlæg argumenterer du jo selv - via et retorisk spørgsmål - for at fjerne ODF og derved kun have et standard-format, OOXML, til udveksling. Så er vi jo enige om kun at have eet format - Vi er blot uenige om hvilket format, der skal benyttes.


Som du siger, så var det et retorisk spørgmål og var primært rettet imod ODF i ISO. Jeg har som sådan ingen holdning til, om OASIS bruger tid på ODF eller ej.

Det er det, jeg forventer du ville gøre. Det er det, jeg forventer at de ansvarlige for det engelske valg af standardformat har gjort.


Beslutningen i UK er højest sansynlig en embedsmandsbeslutning - ligesom beslutningen om åbne standarder var i Danmark.

Du argumenterer for kun at benytte OOXML


Jeg går IKKE ind for et valg af udelukkende OOXML som standard - nogen steder. Jeg går ind for, at man vælger begge standarder, da begge standarder er i markedet (med større eller mindre markedsandel). Det er også korrekt, at OOXML i mine øjne er en meget bedre kandidat som dokumentformat, hvis man ønsker god interop ifht resten af det marked man opererer i. Men det er ikke det samme som at jeg synes, at OOXML skal være eneste standard, der tillades.

Er det det man ønsker i et udvekslings format ?


Måske ikke - men hverken ODF eller OOXML er designede som "udvekslingsformater". De er designede for at man som bruger kan arbejde i et dokument, lukke det og senere åbne det igen og fortsætte, hvor man slap. Som udvekslingsformater er både OOXML og ODF alt, alt for komplicerede og produktspecifikke til at de bør forstås som "udvekslingsformater".

Jeg er klar over, at i virkeligheden, så bruges de netop som udvekslingsformater, men det er ikke det samme som at de er specielt velegnede til det.

Hvis man kun vælger ODF har de øvrige producenter en større chance for komme ind på markedet.


Dette er en påstand, som IMO mangler enhver form for empirisk grundlag. Jeg er klar over, at det ofte er ODFs snakeoil, men jeg mangler endnu at se empiriske fakta, der peger i den retning.

Hvis man benytter begge formater til udveksling vil der altid være bøvl, hvis man modtager data i et format, som er dårligt understøttet af sit office system.


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

MSO -> ODF bliver ALDRIG så god som OO/LO -> ODF, så indtil MSO afgår ved døden, er det bare så touch luck for brugerne af MSO?

Og Microsoft tvinges til bedre support af ODF.


Hvad mener du Microsoft skal gøre mere end, hvad de allerede har gjort - altså udover at fjerne funktionalitet i deres program? Hvad kan Microsoft gøre bedre end de allerede gør?

Med Microsofts dominerende markedsandel medfører det et de-facto valg a "kun OOXML" med de føromtalte konsekvenser.


Igen, det er et udsag uden sagligt grundlag. Hele grunden til at OO/LO overhovedet er her og indgår i markedet er jo netop, at de havde ekseptionel god interoperabilitet med Microsoft Office via de binære dokumentformater. Hvis du tror, at OO/LOs succes skyldes ODF, så tager du markant fejl. Deres succes skyldes, at de med deres understøttelse af dokumentformatet i Microsoft Office kunne indtræde på lige niveau i et økosystem, der for 90% vedkommende bestod af Microsoft Office installationer. Denne succes er man imo ved at smide ud med badevandet ved at insistere politisk på ODF, for ved at bruge ODF, kommer man ALDRIG til at indgå i økosystemet på samme måde som man gjorde med de binære dokumentformater - uanset hvor god Microsofts implementering af ODF er.

  • 0
  • 3
Jesper Lund Stocholm

Jeg medgir, at valget er foretaget på et meget lille og snævert grundlag.


Er din konklusion så ikke ret ligegyldig (undskyld mig)? Vi kan jo ikke diskutere noget som helst på baggrund af en oversigt over, hvordan OOXML og ODF hver især specificerer "rød farve". Et langt bedre grundlag er da, hvordan udviklerne forholder sig til standardens tekst (jvf min reference til ODF bugtrack liste over fejl i standarden).

  • 0
  • 3
Jesper Lund Stocholm

LibreOffice har klaphatte til at implementere OOXML-importen i LibreOffice.


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

Perhaps the OO/LO communities should look to China for some new, capable development talent. Over the past few years CS students at Beihang University and BISTU in Beijing have developed a pretty robust translator that converts documents between Open XML and Uniform Office Format (China’s XML-based document format standard). The recently released update to the UOF Translator adds support for translating “Strict” Open XML documents. These university students were able to master the “complexity” that apparently has completely stumped the “experts” Mr. Feilner cites in his article to handle both Strict and Transitional documents in the same code. Oh, and this project is also open source, so maybe the experts can look to that code for some help.

:-)

  • 0
  • 3
Bo Victor Thomsen

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

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

  • 3
  • 0
Bo Victor Thomsen

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

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

  • 4
  • 0
Bo Victor Thomsen

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

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

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

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

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

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

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

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

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

  • 5
  • 0
Michael Rasmussen

Diskussionens kerne mellem Jesper og hans fløj samt øvrige IT-folk kan sammendrages til følgende:

Jesper: To standarder for samme funktionalitet er bedre en een.
Øvrige: Een standard for samme funktionalitet er bedre en to.

Jespers holdning står så i skærende modstrid til fundatserne for internationale standard organisationer, hvor det er normal praksis, at man har een standard for samme funktionalitet.

Skulle Jespers holdning være normen, ville vi have flere standarder for email, flere standarder for definitionen af en byte, flere definitioner for tallet Pi. Længden af en Mile ville være forskellig alt efter hvilket land man befandt sig i, så bilister skulle medbringe omregningsformel, have installeret avanceret omregningsudstyr i speedometret, eller bilerne skulle udstyres med to eller flere speedometre.

Ovenstående giver sikkert mere beskæftigelse og profit for virksomheder involveret i de forskellige brancher, men en ting er sikkert, omkostningerne for forbrugerne bliver ikke lavere.

  • 6
  • 0
Jeppe Rørbæk

Hej Michael...

Du skriver at det Jesper skriver, kan sammendrages til at;
"To standarder for samme funktionalitet er bedre en een".
Hvis det er det du har udledt af det Jesper skriver, synes jeg du skal bruge din tid på andre debatter.

Hvis det du ville have skrevet var;
"Jesper mener at to standarder for dokumentformater er bedre en én, I INDEVÆRENDE KONTEKST", så vil jeg meget gerne læse mere af hvad du skriver.

Du skriver at det er normal praksis at have een standard for samme funktionalitet, og skriver om biler og billiister. Helt fint ... Har du tjekket farven på baglygterne på bilerne på den anden side af Atlanterhavet for nylig?

Så nævner du en mile, som i allerhøjeste grad ER forskellig fra land til land!
Faktisk ville det have været bedre hvis du havde valgt en gallon - den giver færre udfald, men værdien 1 gallon kan du ikke være sikker på at du kan bestemme uden kontekst.

Og
Billister SKAL have en omregningsformel med i biler i udlandet, hvis de ønsker at kunne relatere angivelsen på speedometeret til en hastighed de kender.

PI er det eneste af det du nævner der giver mening. Det er ikke noget der skifter fra land til land, men det skifter i høj grad over tid, efterhånden som præcisionen forøges.

Som jeg læser Jespers indlæg i forhold til dit, så har Jesper forstået at
"The world is upon us", og det forholder han sig til.

Det synes jeg også du skal gøre.

Ft.bbr.t
Jeppe

  • 1
  • 7
Jesper Lund Stocholm

Tjah, i så fald er der en rigtig lang række af blog indlæg - inklusive det oprindelige blogindlæg der er udgangspunktet for denne diskussion - som er inderligt ligegyldige.


Blogindlæg og holdninger kan vel ikke være ligegyldige - men konklusionerne deraf kan naturligvis. Og en konklusion omkring forholdet imellem fx ODF og OOXML, der er baseret på - i dine egne ord - meget begrænsede data, er ligegyldig. Du er velkommen til at være uenige i mine konklusioner, men jeg forsøger at basere dem på noget faktuelt - som fx antallet af uklarheder i ODF, der er overvældende. Hvis du er uenig i dette, kunne du jo starte med at forklare, hvorfor dette ikke er et problem for leverandører.

  • 0
  • 2
Jesper Lund Stocholm

At benytte to eller flere indbyrdes inkompatible dokumentformater vil medføre enten fortolknings eller konverteringsproblemer hos modtager,
når modtager og afsender benytter hvert sin tekstbehandler.


Og dette flytter jo blot problemet længere væk. Konvertering vil ALTID skulle foretages. Du kommer ikke udenom det ved at bruge ét format.

Ideelt set burde man have det simplest mulige redigérbare, leverandøruahængige format.


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

Hvis jeg lige pludselig stod i en situation, at jeg havde reel indflydelse på valget af format, ville jeg selvfølgelig afgøre mit valg på helt anderledes grundige undersøgelser. Og måske komme til en anden konklusion.


Jeps - og det er jo præcist dér, hvor jeg står. Jeg har ikke indflydelse på selve valget af formatet, men jeg har reel indflydelse på, hvordan formaterne udformes. Hvorfor bliver du ved med at holde fast i dine "meget begrænsede" forsøg i stedet for at lytte til mig?

Valget af standard format vil give den tekstbehandler, som benytter udvekslingsformatet internt "vind i sejlene".


Igen - dette er i mine øjne en konklusion uden sagligt grundlag. Jeg tror ikke på, at Microsoft Office skulle blive mere fordelagtigt stillet ved valg af OOXML. Og jeg tror heller ikke på, at OO/LO lige pludseligt vil få mere vind i sejlene, hvis ODF alene vælges. Vi er langt forbi den tid i 80/90'erne, hvor dokumentformater var proprietære og binære og ikke-dokumenterede.

Til gengæld er det guds givet, at hvis man vælger en løsning med "ODF only", så vil en stor del af brugerne i dag komme til at opleve problemer.

  • 1
  • 3
Jesper Lund Stocholm

Jespers holdning står så i skærende modstrid til fundatserne for internationale standard organisationer, hvor det er normal praksis, at man har een standard for samme funktionalitet.


Hey, 2008 ringede - de vil gerne have deres ævl tilbage.

For det første:

i skærende modstrid til fundatserne for internationale standard organisationer

Dette er faktuelt forkert. Spørgsmålet om to standarder med funktionelt overlap (som det er tilfældet med ODF og OOXML) blev indgivet som officiel klage under standardiseringen af OOXML i 2007/2008. Den blev behandlet på højeste sted i JTC1 (der er øverste organ for bla. dokumentformater i ISO) og det blev konkluderet, at der ikke var noget i "fundatserne", der talte imod at standardisere OOXML - selvom ODF allerede var en ISO standard.

For det andet:

det er normal praksis, at man har een standard for samme funktionalitet

Dette er faktuelt forkert - specielt i IT-verdenen. Der er mange standarder for billedformater i ISO (JPEG, PNG etc) og der er mange standarder for videoformater (MPEG2, MPEG4 etc). Der er flere ISO-standarder for lydformater ... og man kan blive ved.

Kan vi komme videre nu?

  • 1
  • 3
Palle Simonsen

Til gengæld er det guds givet, at hvis man vælger en løsning med "ODF only", så vil en stor del af brugerne i dag komme til at opleve problemer.

Jesper jeg synes dette ligner et partsindlæg til fordel for den ene part i en nu bilagt formatstrid.

Hvad er det for nogle store problemer du forudser og som åbenbart ikke har afhold England fra at vælge ODF?

  • 3
  • 0
Jesper Lund Stocholm

Som jeg læser Jespers indlæg i forhold til dit, så har Jesper forstået at
"The world is upon us", og det forholder han sig til.


Tak :-).

På mange måder kan dit udsagn siges at være definerende for, hvor ODF står i dag. På det aller, aller, aller første møde i ODF TC skulle man beslutte sig for en fremtidig retning for udviklingen af dokumentformatet i Suns OpenOffice, og her valgte man eksplicit at vedtage, at man ikke ønskede at søge kompatibilitet med dokumentformatet i Microsoft Office.

Referatet fra mødet kan findes på ODF TCs hjemmeside i deres arkiv, hvis man er interesseret i det.

Man valgte altså at se bort fra situationen på markedet, hvor den førende kontorpakke (Microsoft Office) vel reelt havde endnu større markedsandel end den har i dag. Og det drejede sig jo ikke om, at man ville implementere funktionalitet på samme måde som i Microsoft Office (det ville jo ikke være noget problem ifht konvertering, hvis det var tilfældet) - man valgte at se bort fra funktionalitet, som man ikke ønskede at forholde sig til.

Og populært sagt kan man sige, at "resten er historie". Problemerne med konvertering imellem OOXML og ODF kan præcist dateres tilbage til dette møde, hvor man valgte at tage skyklapper på og ikke forholde sig til resten af verden.

Jeg synes, at det er beundringsværdigt, når gode folk sætter sig ned og vender bøtten på hovedet og forsøger at lave noget nyt på en bedre måde end det eksisterende. Det synes jeg også med ODF. Men kæden hopper i den grad af for mig, når selvsamme folk 10 år senere kommer og agiterer for global brug af udelukkende deres format og samtidig enten negligerer de problemer, som de selv valgte at acceptere på første møde eller postulerer, at problemerne udelukkende er modpartens skyld.

Og en sidste ting, som jeg ikke har nævnt før i nærværende debat:

Det er åbenbart ikke gået op for særligt mange af ODF-elskerne, hvad der er blevet besluttet i England.

Man har besluttet, at for redigerbare dokumenter, der udveksles (imellem offentlige myndigheder) i England, skal formatet være ODF.

Med andre ord skal ODF bruges som dokumentformat i en redigeringsproces - hvilket i sagens natur medfører brug af ændringsmarkering.

Og lige præcist her kan ODF ikke løfte opgaven - end ikke til et acceptabelt niveau. Ændringsmarkering i ODF er mildest talt mangelfuld. Dette blev på peget allerede i 2010, hvor Lars Garshol fra Norge (der sad i den norske standardiseringskommitte og af den norske regering blev bedt om at analysere OOXML og ODF. Hans kommentater omkring ændringsmarkering var:

For ODF:

The handling of change tracking in running text is quite fair, but doesn't seem to be complete. Change tracking in tables, lists, formulas, etc is missing.

For OOXML:

OOXML spends 120 pages on this, a lot of them duplicated. The functionality is very detailed, going into table changes, formatting changes, list numbering changes, etc etc. I couldn't digest it all, but as far as I could tell it was solid.

Ovenstående stemmer overens med mine egne erfaringer.

Hvis man kigger i kommentartråden, så vil man kunne se, at Rob Weir (dengagng Co-chair for ODF TC) går i forsvarsposition og begynder at spekulere i årsagen til dette, og her svarer Lars nogenlunde dette:

"Det nytter ikke noget at begynde at tærske langhalm på, hvorfor en funktionalitet ikke er anvendelig - ved valg af format til brug for myndighederne er vi nødt til kun at forholde os til, at funktionaliteten ikke er til stede.

Eller som du siger, "the world is upon us".

Som det ses ovenfor, så ønsker ingen af kongratulanterne af Englands beslutning at forholde sig konkret til problemerne ved valg af ODF alene. Man ønsker kun at diskutere påstande om øget konkurrence - påstande, der er uden empirisk evidens eller om, at Microsoft ikke gør det godt nok med deres implementering af ODF.

http://www.garshol.priv.no/blog/211.html

  • 2
  • 3
Henrik Madsen

Jeg deltog som DTU's repræsentant i udvalget som behandlede OOXML forslaget hos Dansk Standard i perioden fra ca. 2006 til 2008. Inden da var ODF 1.0 blevet en ISO standard. Forløbet i ISO / DS omkring behandlingen af Microsofts forslag (OOXML) var på mange måde helt vanvittig/grotesk, og derfor endte vi med (på linie med en række andre) helt at trække os fra dette arbejde hos DS; det gav simpelthen ingen mening. Reelt køres det vel i dag af Microsoft og deres partnere.

Som eksempel på den groteske behandling kan det nævnes, at der både i DK (og andre lande) var et stort flertal i udvalget som stemte imod at forslaget (OOXML) skulle godkendes som en åben standard (et stort flertal anbefalede DS at stemme 'nej' til ISO). Alligevel stemte DS 'ja' ved den endelige afstemning i marts 2008. Denne lange række af groteske episoder i ISO/DS kan være baggrunden for at personerne bag den udmærkede ODF 1.2 (som drives af OASIS) har tøvet med at bringe den til ISO. Jeg hæfter mig også ved, at Alex Brown, som var leder af et stort (men også tvivlsomt møde i Geneva inden de endelige behandlinger i de enkelte lande), nu også mener, at OOXML er på vej til at fejle - se bla.:

http://www.consortiuminfo.org/standardsblog/article.php?story=2010040107...

Vi mener derfor, at det er yderst vigtigt, at ODF 1.2 får en fair behandling i ISO, og i lighed med det store flertal i denne tråd så foretrækker vi også ODF fremfor OOXML (selv her ca. 6-7 år efter er Microsoft ikke selv i stand til at implementere OOXML Strict). Baggrunden for at jeg foretrækker ODF fremfor OOXML er bla. følgende:

1) XML teksten i ODF kan stortset altid læses direkte; det er langt vanskeligere for OOXML

2) ODF er baseret på eksisterende standarder

3) ODF fylder langt mindre på harddisken end OOXML

4) ODF er langt hurtige at parse (da vi undersøgte det i 2008 var det ca. 5-6 gange hurtige at læse et ODF dokument end et OOXML dokument).

5) ODF kan implementeres på stortset samtlige platforme (operativsystemer), og dermed kan vi sikre den interoperabilitet som er så vigtig (også for standarder).

6) ODF standarden fylder mindre end 1000 sider medens OOXML fylder 7-8000 sider (ret mig venligst om nødvendigt).

Som Rob Weir (IBM) flere gange har sagt, så er XML for office-dokumenter ikke 'raket-videnskab'. Ned den fornødne vilje ville man let 'kunne få det til at virke' - også på tværs af platforme.

Jeg er utryg ved at Jesper (fra Microsoft Gold-partneren Ciber) gennem flere år har stået i spidsen for dette arbejde hos DS (men desværre viste behandlingen af OOXML i 2006-2008 at det ikke giver mening for os at deltage). Blandt andet mener jeg, at Jesper (se også denne tråd) har misforstået prioriteringerne ift. interoperabilitet. Som almindelig bruger af office dokumenter er det interoperabilitet mellem office systemer (OpenOffice, MS-Office, LibreOffice, mv.) samt mellem platforme (såsom Android, Windows, Linux, iOS, mv.) som har interesse - og IKKE at kunne konvertere mellem OOXML og ODF. Denne konvertering bør der ikke bruges kræfter på; dertil er de 7-8000 sider som beskriver OOXML standarden alt for svag/ulæselig, og det vil helt sikkert altid være en ret umulig opgave.

  • 3
  • 2
Jesper Lund Stocholm

Jesper jeg synes dette ligner et partsindlæg til fordel for den ene part i en nu bilagt formatstrid.


Det er det ikke.

Hvad er det for nogle store problemer du forudser og som åbenbart ikke har afhold England fra at vælge ODF?


Se min kommentar ovenfor om ændringsmarkering.

Kort sagt: hver gang en bruger af Microsoft Office laver et dokument med ændringsmarkering i (der berører andet end basal tekst, dvs ændrer i andre "normale" dele af et tekstdokument, såsom billeder, tabeller, punktlister, formler etc), så vil disse informationer forsvinde ved konvertering til ODF - også selvom modtager-kontorpakken også er Microsoft Office.

Jeg ved ikke, hvad fordelingen imellem MSO/OO er i UK, men hvis vi for sjov leger, at den er 80/20, så vil ovenstående give problemer, hver gang en af de 80% sender et dokument til de andre 80% af MSO-brugerne (fordi dokumentet skal konverteres til ODF inden afsendelse). Hvis man ikke kun kunne bruge ODF, så ville det "kun" give problemer, når man sendte i OOXML til OO/LO.

Problemet med ændringsmarkering er ODF er så udtalt, at man i ODF TC i 4 år har arbejdet med at få det på plads og har reelt afsat næste version af ODF (1.3) til primært at være fix af ændringsmarkering. Rygterne på vandrørene siger dog, at det er tvivlsomt, om de overhovedet når at blive enige til 1.3. De kan nemlig ikke engang blive enige om, på hvilken måde det skal implementeres.

Hvis man i ODF-community havde nogen form for rygrad og overhovedet bekymrede sig om brugerne af deres programmer (og ikke kun at bitche over Microsoft), så ville de havde sagt til folkene i UK:

"Ved I hvad? Vi er glade for, at I har valgt ODF som format for redigerbare dokumenter, men vi synes reelt ikke, at ODF kan løfte denne opgave. Vi vil foreslå, at I afventer ODF 1.3 og til den tid kigger på, om vores format er noget for jer. Indtil da synes vi, at I skal kigge på nogle af de andre dokumentformater, der er derude".

  • 0
  • 3
Michael Rasmussen

Dette er faktuelt forkert. Spørgsmålet om to standarder med funktionelt overlap (som det er tilfældet med ODF og OOXML) blev indgivet som officiel klage under standardiseringen af OOXML i 2007/2008. Den blev behandlet på højeste sted i JTC1 (der er øverste organ for bla. dokumentformater i ISO) og det blev konkluderet, at der ikke var noget i "fundatserne", der talte imod at standardisere OOXML - selvom ODF allerede var en ISO standard.


Nu er der jo ikke tale om funktionelt overlap, men komplementerende standarder!

Dette er faktuelt forkert - specielt i IT-verdenen. Der er mange standarder for billedformater i ISO (JPEG, PNG etc) og der er mange standarder for videoformater (MPEG2, MPEG4 etc). Der er flere ISO-standarder for lydformater ... og man kan blive ved.

Dette er lige så faktuelt forkert, da der mig bekendt ikke findes to standarder for eksempelvis JPEG eller MPEG4!

Mit udgangspunkt er, at der ikke blot er tale om funktionelt overlap, men to konkurrende standarder for den samme funktion: Lagring af tekst i redigerbart format. Derfor holder din argumentation ved at sammeligne med billed og videostandarder heller ikke. For billed og videostandarder er der rigtigt nok tale om funktionelt overlap, men sammenligner du f.eks mellem JPEG og PNG er deres mål forskellige. JPEG er blevet udviklet med henblik på at kunne gemme analoge billeder digitalt, mens PNG er udviklet med henblik på et generelt billedformat uden brug af patenterbare algoritmer, som skulle erstatte GIF formatet, da der var licensrettigheder forbundet med kommercielt brug af GIF.

  • 1
  • 1
Jesper Lund Stocholm

Nu er der jo ikke tale om funktionelt overlap, men komplementerende standarder!

Uanset hvordan du vælger at se på det, så blev det undersøgt at øverste instans i ISO/JTC1 og deres konklusion var, at der ikke var noget til hinder for at standardisere OOXML.

Du kan naturligvis være uenig - men det er faktuelt forkert at påstå, at der er et problem med standardiseringen af OOXML i sig selv.

sammenligner du f.eks mellem JPEG og PNG er deres mål forskellige.


Og målene med ODF og OOXML er også forskellige. Målet med OOXML er at have en ISO-standard, der sikrer kompatibilitet med Microsoft Office. Dette er ikke målet med ODF.

Havde Microsoft Office haft en markedsandel på 10%, så var der aldrig blevet en ISO-standard ud af det med nuværende formål. Men Microsoft Office har en markedsandel på 80-90%, og derfor er interop med den naturligvis vigtig - alene ifht konkurrence.

  • 1
  • 2
Bo Victor Thomsen

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

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

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

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

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


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

  • 1
  • 0
Peter Stricker

her valgte man eksplicit at vedtage, at man ikke ønskede at søge kompatibilitet med dokumentformatet i Microsoft Office.


Det lyder da også meget fornuftigt. Dokumentformatet for Microsoft Office var jo ikke specificeret. Og det er jo ikke det samme som, at man eksplicit har valgt at opnå størst mulig inkompatibilitet til det udokumenterede dokumentformat i Microsoft Office.

Må jeg omvendt spørge dig, hvor stor en del af specifikationen af ISO 29500, der eksisterer udelukkende for at sikre størst mulig kompatibilitet med ODF?

  • 2
  • 0
Jesper Lund Stocholm

Hvis du mener at Microsoft Office ikke står bedre, hvis man kun benytter OOXML som udvekslingsformat, så har jeg et tårn i Paris og en bro i New York, jeg gerne vil sælge til dig.


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

Jeg gentager gerne: Grunden til OO/LOs success har (historisk set) været på grund af deres ekceptionelle håndtering af dokumentformatet (det binære) i Microsoft Office. Jeg har selv utallige gange (og jeg er sikker på, at det er det samme for de fleste herinde) argumenteret for brug af OO/LO med netop argumenterne om, at de kunne åbne filerne fra Microsoft lige så godt som Microsoft Office - og i nogle tilfælde bedre.

Så evidensen peger på, at hvis du ønsker bedre konkurrence, så skal det ske med god interoperabilitet til Microsoft Office. OOXML giver mulighed for denne interoperabilitet - ODF gør det ikke, og kommer ikke til det.

  • 0
  • 2
Henrik Madsen

Jesper; her må nu nok hjælpe mig. Jeg ringede til underdirektør Jesper Jerlang, og han sagde kort, at 'det skyldes pres udefra' - mere fik jeg ikke at vide, og jeg forstod aldrig hvordan det kunne give mening at en lang række personer (fra firmaer, universiteter, regioner, mv) brugte ca. 3 år på at evaluere Microsofts forslag til en ISO standard (OOXML), og selvom et stort flertal i udvalget i DK (og Norge - som jeg også kender en del til) konkluderede at den var ubrugelig som en åben standard og derfor stemte 'nej', så valgte DS (og tilsvarende organisationer i lang række andre lande) alligevel at stemme 'ja'. Måske du kan hjælpe? For mig giver det ikke menig. Burde vi ikke være advaret inden vi gik igang (så kunne vi have brugt tiden på noget langt mere fornuftigt - f.eks. ODF)? Måske du kan forklare det ...?

  • 3
  • 0
Bo Victor Thomsen

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


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

  • 3
  • 0
Jesper Lund Stocholm

Jesper; her må nu nok hjælpe mig. Jeg ringede til underdirektør Jesper Jerlang, og han sagde kort, at 'det skyldes pres udefra' - mere fik jeg ikke at vide


Henrik,

DTU og CIBER trådte ind i DS på nogenlunde samme tid (i sommeren 2007, så vidt jeg husker). Vi var begge medlemmer, da mødet i september 2007 blev holdt, og vi var begge medlemmer i tiden frem til mødet i marts 2008.

Du ved altså præcist, hvad der skete, og jeg forstår derfor ikke, hvorfor du ikke bare fortæller, hvad der skete - i stedet for at referere til en telefonsamtale, som ikke kan bekræftes og indholdet ikke kan verificeres.

Men lad mig da så fortælle det. Der er i øvrigt et offentligt papirspor (vi offentliggjorde alle referater og beslutninger) på DS's hjemmeside), der dokumenterer, hvad jeg nu fortæller.

Du siger, at "et stort flertal anbefalede DS at stemme 'nej' til ISO", men sandheden var jo, at HELE udvalget anbefalede DS at stemme "nej" i 2007. Udvalgets indstilling (som hele udvalget stod bag) til DS var, at der var for mange fejl (vi havde indsendt en liste på 168 fejl, som jeg husker det) i OOXML til at den kunne godkendes.

Udvalget sagde også til DS, at såfremt disse fejl rettes, vil DS ændre stemmen til "ja".

I de efterfølgende måneder gik et teknisk underudvalg i gang med at sørge for, at disse 168 fejl blev rettet. Udvalget bestod bla. af

Aarhus Kommune
CIBER
Ementor
IBM
Microsoft
ORACLE

Vi indgik i tæt arbejde med ISO om dette og knoklede for at få konstrueret ændringsforslag til de 168 fejl til det kommende BRM-møde.

Da vi tog til BRM-mødet (det var DS, CIBER, IBM og Microsoft) havde vi 168 ændringsforslag med til OOXML, som var godkendt af det samlede udvalg. Vores mandat var at forsøge at få disse godkendt enten i den eksisterende form eller i en bedre version.

Da vi kom hjem var det med en liste med 168 grønne krydser, dvs ALLE ændringsforslag var stemt igennem i enten oprindelig form eller i forbedret udgave.

Alle beslutninger ovenfor skete i enighed i udvalget, og der er underskrifter fra alle deltagere til møderne på alle referater.

Så når du nu påstår, at du ikke kan forstå, hvorfor DS stemte "ja", så må det - i heldigste fald - bero på en misforståelse.

For i forkortet form kan ovenstående jo formuleres således:

September 2007: Et enigt udvalg i DS siger, at vi stemmer nej, men hvis vores 168 indsigelser accepteres, vil vi ændre stemmen til et "ja".

Februar 2008: 168 indsigelser accepteres som ændringer til OOXML

Marts 2008: DS stemmer "ja".

Min personlige kommentar:

Jeg er helt overbevist om, at ODF-fløjen i 2007 bluffede, da de sagde, at de ville stemme "ja", hvis de 168 ændringsforslag blev accepteret. Jeg tror ikke, at de i deres vildeste fantasi havde forestillet sig, at Microsoft i den grad ville lægge sig på ryggen og acceptere så mange ændringer til deres format (det havde jeg nu heller ikke troet). Men pludseligt stod de så i en situation, hvor rettelserne blev indføjet ... og hvad skulle de så gøre nu? Det er muligt, at det ikke var en juridisk bindende aftale man lavede med ISO, men når man indgår i et professionelt samarbejde, så forventes det jo, at man holder, hvad man lover. Det er jo ingen børnehave. Så nu var man jo nødt til at finde på nogle konspirationsteorier, der kunne dække over den eklatante brøler de havde lavet. Konspirationsteorier netop som den med at DSs direktør i en telefonsamtale havde været udsat for pres, eller al den anden "information", der blev "lækket" fra det sidste møde i de efterfølgende dage ...

  • 2
  • 2
Esben Nielsen

Jeg er helt overbevist om, at ODF-fløjen i 2007 bluffede, da de sagde, at de ville stemme "ja", hvis de 168 ændringsforslag blev accepteret. Jeg tror ikke, at de i deres vildeste fantasi havde forestillet sig, at Microsoft i den grad ville lægge sig på ryggen og acceptere så mange ændringer til deres format (det havde jeg nu heller ikke troet).

Nu kender jeg ikke detaljerne i dette, men kan det være at Microsoft gik med til rettelserne, da de alligevel aldrig ville rette deres implementation men kun behøvede en standeard, som ingen nogensinde har implementeret alligevel, for at give de offentlige kunder et figenblad for at anvende Microsofts fil-format?

  • 4
  • 0
Henrik Madsen

Jesper,

Du husker formodentlig også, at vi om onsdagen (inden DS' indmelding til ISO om fredagen - en gang i marts 2008) havde en (måske lidt uformel) afstemning hvor et stort flertal stemte 'nej' (som jeg husker det var det 8 mod 4). Du kan bare søge på f.eks. Version2 omkring dette tidspunkt; der var en ret livlig debat om denne afstemning. Tilsvarende vil enhver kunne søge under afstemningen i Norge, hvor også et stort flertal stemte 'nej'. I begge tilfælde var den efterfølgende chokerende indmelding til ISO et 'ja' - på trods af at ekspertudvalgene mente det modsatte. Enhver vil også ved almindelig søgning se at der skete mange, mange mærkelige ting under behandlingen af OOXML.

Som vi påstod allerede i 2007-8 så er OOXML ikke egnet som en åben standard, og her 6-7 år efter må vi vel konkludere at vi fik ret; vi har ikke fået den interoperabilitet, som det må forventes at en reel åben standard kan give (og for os som læste lidt i de ca. 7000 sider, som OOXML fyldte på dette tidspunkt, er det ikke overraskende). ODF vil derimod kunne give denne interoperabilitet (og mange andre fordele - læselig standard, mindre pladskrav på harddisken, hurtigere læsning, mv.), og derfor synes jeg, at flere burde følge England og vælge/prioritere ODF.

  • 3
  • 0
Sune Marcher

Tys.

Både ODF og OOXML er decideret retarderede "standarder". De er dårligt specificerede (se hvad Morten Welinder har at sige om fx OOo calc), og som format i sig selv er der ca. ingenting der er godt ved nogen af de to formater.

Begge formater er decideret retarderede, og fungerer ikke særligt godt når man arbejder med dokumenter der er en smule længere end et par enkelte sider. Ingen af dem burde være ISO standarder, de er begge lort med lort på.

ODF er klart bedre end OOXML, men det gør det stadig ikke til et godt format. PDF er et nogenlunde ikke-retarderet format til lagring af statisk tekst - vi mangler stadig noget til redigérbart text...

KISS, interchange med det offentlige behøver ikke at supportre kitchen-sink.

  • 3
  • 0
Jørgen Henningsen

ODF er klart bedre end OOXML, men det gør det stadig ikke til et godt format. PDF er et nogenlunde ikke-retarderet format til lagring af statisk tekst - vi mangler stadig noget til redigérbart text...

ODF Formatet er ikke fuldt modnet, men ideen er vel også at arbejde mod et godt fælles format. Det er et skridt i den rigtige retning at bruge åbne royalty-fri standarder.

  • 3
  • 0
Jesper Lund Stocholm

Det lyder da også meget fornuftigt. Dokumentformatet for Microsoft Office var jo ikke specificeret.


Det er faktisk ikke helt korrekt. En stor del af de binære dokumentformater var specificerede, og man kunne bestille denne specifikation hos Microsoft. Jeg gjorde det selv i 2007, da jeg trådte ind i udvalget i DS.

Det er korrekt, at ikke ALT var specificeret, men OO havde jo formået at få så meget af det implementeret alligevel, at alle brugte som argument for at bruge OO, at den havde super god understøttelse for formaterne. Så udviklerne bag OO havde i hvert fald detaljeret viden om funktionaliteten - selvom den ikke var specificeret særligt godt. Husk også på, at der intet funktionelt er til forskel på de binære dokumentformater og den specifikation, der blev indleveret til ISO (bortset fra DrawingML og formelspecifikationen i Word, så vidt jeg husker).

Og det er jo ikke det samme som, at man eksplicit har valgt at opnå størst mulig inkompatibilitet til det udokumenterede dokumentformat i Microsoft Office.


Det er der vel heller ikke nogen, der har sagt.

Må jeg omvendt spørge dig, hvor stor en del af specifikationen af ISO 29500, der eksisterer udelukkende for at sikre størst mulig kompatibilitet med ODF?


En stor del af de kommentarer, der kom ind via ISO-processen udtrykte specifikt ønske om bedre interop med bla. ODF. En stor del af den funktionalitet, der nu hedder "Strict" blev designet, så det var nemmest muligt at konvertere til andre formater - i modsætning til hvordan man oprindeligt havde foreslået fra Microsofts side. Disse "gamle" ting ligger nu i "Transitional".

Den eneste ting jeg ved med sikkerhed ikke kan konverteres fra ODF til OOXML er kryptering af dokumenter - og det skyldes, at denne funktionalitet ikke eksisterer i OOXML-formatet.

  • 0
  • 3
Jesper Lund Stocholm

Nu kender jeg ikke detaljerne i dette, men kan det være at Microsoft gik med til rettelserne, da de alligevel aldrig ville rette deres implementation men kun behøvede en standeard, som ingen nogensinde har implementeret alligevel, for at give de offentlige kunder et figenblad for at anvende Microsofts fil-format?


Jeg er helt sikker på, at mange opfattede Microsofts handlinger dengang i 2008 med netop denne vinkel.

Men - OOXML blev godkendt i 2008. I maj 2009 blev første beta af Office 2010 frigivet, og i juni 2010 kom den endelige version. Denne version havde læseunderstøttelse for Strict. Med Office 2013 kom så understøttelse af både læsning og skrivning af Strict dokumenter.

Så Microsoft har sådan set vist, at det ikke kun var tomme ord dengang i 2008.

  • 0
  • 3
Jesper Lund Stocholm

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


Ja, og om et par år, kan vi så vide, om det gav det ønskede resultat. Dette ved vi intet om endnu. Vi ved til gengæld, at god interop med Microsoft Office's dokumentformat giver øget konkurrence. Alt andet er gætterier.

  • 0
  • 3
Jesper Lund Stocholm

ODF Formatet er ikke fuldt modnet, men ideen er vel også at arbejde mod et godt fælles format. Det er et skridt i den rigtige retning at bruge åbne royalty-fri standarder.


Så det man siger til brugerne er dermed:

Vi ved godt, at ODF ikke kan løfte opgaven med at være interoperabilitets-format for redigerbare dokumenter, men vi kræver alligevel, at I skal bruge det, for hen ad vejen bliver det sikkert godt.

Hurra.

  • 0
  • 3
Jesper Lund Stocholm

Det er ikke meget forskelligt fra PDF/XPS. Hvorfor skal MS absolut gå deres egne veje og ikke bare støtte op om de fuldt ud åbne standarder der findes i forvejen?


Så vidt jeg ved, støtter Microsoft da fuldt op omkring PDF og PDF/A. Som jeg husker det, så sidder de også i standardiseringsgrupperne for netop PDF (og varianter). Den er i hvert fald implementeret i en lang række af deres produkter, og i Office 2013 kan man endda redigere i PDF-dokumenter.

Men det er jo ikke det samme som at man ikke kan udvikle sig. XPS er jo en ECMA-standard, og den primære fordel ifht PDF er jo, at den er XML-baseret. PDF er jo reelt et "binært dokumentformat".

Personligt kan jeg langt bedre lide at arbejde med XML-baserede dokumentformater som OOXML og ODF end med fx de binære dokumentformater i Microsoft Office, og jeg vil da tro, at jeg ville komme til samme konklusion, hvis jeg begyndte at arbejde med XPS ifht PDF.

Men sådan er vi jo så forskellige :-)

  • 0
  • 2
Jesper Lund Stocholm

Som vi påstod allerede i 2007-8 så er OOXML ikke egnet som en åben standard


Hvorfor skrev du så under på, at du ville stemme "ja", hvis de 168 ændringer gik igennem?

Husk også på, at udvalget i DS jo tillige reelt havde en short-list på omkring 40 rettelser, som var de vigtigste. Vi tog til Geneve med det mandat, at det vigtigste var at få de 40 igennem - og resten var sekundær prioritet.

Jeg kan kun tolke din kommentar her som at for dig, retfærdiggjorde målet om ikke at godkende OOXML samtlige midler du kunne komme i tanke om - også at lyve i udvalget.

Det er dælme uprofessionelt af DTUs repræsentant i udvalget - og gør mig flov over, at jeg er dimmitend fra DTU.

Som du ved, var møderne fortrolige, og jeg kan derfor ikke referere fra dem, men hvis du giver mig lov, skal jeg gerne fortælle lidt om, hvad du ellers sagde til møderne dengang - specielt det sidste inden afgørelsen. Det står mejslet ind i min hukommelse.

  • 0
  • 2
Jesper Lund Stocholm

Samtidigt havde vi også været fri for XPS. Det format gavner ingen.


Ja, jeg ved ikke voldsomt meget om XPS (andet end at det bruger container-formatet i OOXML, OPC), men jeg kan da se fra ECMAs hjemmeside, at en lang række fabrikanter af bla. printere åbenbart synes, at det er en god idé.

  • Autodesk
  • Brother Industries
  • Canon
  • Fujifilm
  • Fujitsu
  • Global Graphics
  • Hewlett Packard
  • Konica Minolta
  • Lexmark
  • Microsoft
  • Monotype Imaging
  • Océ Technologies
  • Pagemark Technology
  • Panasonic/Matsushita
  • QualityLogic
  • Ricoh
  • Software Imaging Limited
  • Toshiba
  • Xerox
  • Zoran Corporation
  • 0
  • 0
Peter Stricker

Vi ved til gengæld, at god interop med Microsoft Office's dokumentformat giver øget konkurrence.


Øget konkurrence i forhold til hvad?

Jeg tror at det vil være lettere for konkurrenter til Microsoft Office, at opnå en mindst ligeså god understøttelse af ODF som Microsoft Office har, end tilfældet vil være med OOXML.

Jeg tror derfor, at englændernes valg af ODF vil være til fordel for Microsoft Offices konkurrenter.

Jeg tror at dette på sigt vil betyde en svagere binding til Microsoft Office hos den offentlige administration i England.

Men det er blot noget jeg tror. Jeg vil ikke påstå, at der foreligger empirisk bevis for påstanden.

  • 1
  • 0
Jesper Lund Stocholm

Øget konkurrence i forhold til hvad?


I forhold til dårlig interop med Office. Og ODF kan. ikke. give. god. interop. med. office.

Punktum.

Dertil er funktionalitets-gabet for stort. Der er eksempelvis områder i ODF, hvor der - pga designvalg, der er taget fra ODF 1.0 - ALDRIG vil blive mulighed for konvertering imellem ODF og OOXML.

  • 0
  • 0
Peter Stricker

Der er eksempelvis områder i ODF, hvor der - pga designvalg, der er taget fra ODF 1.0 - ALDRIG vil blive mulighed for konvertering imellem ODF og OOXML.


Kunne du ikke forestille dig, at nogle af de offentlige myndigheder i England så vil skifte kontorsuite til en af dem, der har ODF som deres native format, i stedet for at hænge fast i Microsoft Office?

Og kunne du ikke forestille dig, at et sådant valg, såfremt det bliver taget, vil fremme udbredelsen af OpenOffice og/eller LibreOffice?

Og kunne du ikke forestille dig, at den engelske beslutning om, fremover at bruge ODF, så vil styrke Microsoft Office's konkurrenter?

Det tror jeg, at der er en god chance for. Trods dine empiriske beviser.

  • 1
  • 0
Jesper Lund Stocholm

Kunne du ikke forestille dig, at nogle af de offentlige myndigheder i England så vil skifte kontorsuite til en af dem, der har ODF som deres native format, i stedet for at hænge fast i Microsoft Office?


Tjo - det er da muligt. Men hvis de ønsker at bruge kontorpakken til en redigeringsproces, så er en kontorpakke udelukkende med god understøttelse for ODF (og eksempelvis dårlig support for OOXML) et rigtigt dårligt valg.

Det synes jeg, at man skal være ærlig om. Ellers er konsekvensen jo, at det ikke bliver en god oplevelse med OO/LO - og at man derefter skifter tilbage til fx Microsoft Office, fordi man ikke kan få forventningerne til at passe med realiteterne.

Det tror jeg, at der er en god chance for. Trods dine empiriske beviser.


Det er rigtignok, at der er 20 års empiriske beviser for, at god interop med Microsoft Office via deres dokumentformater giver øget konkurrence. Men der er ingen empiriske beviser for, at en satsning på ODF ikke giver øget konkurrence.

Der er derimod tekniske beviser for, at interop med ODF til Microsoft Office ikke kan blive godt for arbejdsgange, hvori indgår en redigeringsproces af tekstdokumenter. Faktisk er der tekniske beviser for, at ODF til redigeringsprocesser med tekstdokumenter ikke bliver godt i det hele taget.

  • 0
  • 0
Jesper Lund Stocholm

Jesper,

OOXML var heller ikke fuldt modnet da det kom på banen.


Hey - vi snakker altså ikke om dokumentformater, der lige er kommet "på banen". ODF blev godkendt som standard i maj i 2005 i OASIS. Det er næsten 10 år siden, så fraværet af andet end tekstuel ændringsmarkering er ikke et resultat af "vi er nye på markedet, så bær over med os". Det er derimod et resultat af ligegyldighed.

ODF ligger som man har redt. Man har haft næsten 10 år til at gøre noget ved denne åbenlyse mangel, og her 10 år efter lyver man stadig om det og foregøgler myndigheder rundt omkring, at ODF er velegnet til storskala-implementering som dokumentformat for en redigeringsproces.

  • 0
  • 2
Peter Stricker

Men hvis de ønsker at bruge kontorpakken til en redigeringsproces, så er en kontorpakke udelukkende med god understøttelse for ODF (og eksempelvis dårlig support for OOXML) et rigtigt dårligt valg.


Nu har de jo valgt ODF som dokumentformat, så kan det vel være ligemeget om deres kontorpakke har ringe eller slet ingen understøttelse af OOXML.

Ellers er konsekvensen jo, at det ikke bliver en god oplevelse med OO/LO - og at man derefter skifter tilbage til fx Microsoft Office, fordi man ikke kan få forventningerne til at passe med realiteterne.


Da kun, hvis Microsoft Office giver en bedre oplevelse med ODF dokumenter.

Det er rigtignok, at der er 20 års empiriske beviser for, at god interop med Microsoft Office via deres dokumentformater giver øget konkurrence.


Den påstand er du efterhånden kommet med en del gange. Har du et link til en eller flere undersøgelser, der understøtter din påstand? Jeg er ikke interesseret i undersøgelser, der blot viser korrelation. De skal naturligvis også vise kausalitet. Og hvis de lugter blot det mindste af "Get the Facts", så vil du blive bedømt negativt på det.

Der er derimod tekniske beviser for, at interop med ODF til Microsoft Office ikke kan blive godt for arbejdsgange, hvori indgår en redigeringsproces af tekstdokumenter.


Jamen, så må de jo holde sig langt væk fra Microsoft Office. Hvis det bliver konsekvensen af deres valg af ODF, så synes jeg da at man bør hylde beslutningen. For så ser det ud til at være en langt mere effektiv metode til at skabe konkurrence, end den af dig foreslåede metode med størst mulig interoperabilitet med Microsoft Office.

Og jo mere jeg læser dine argumenter mod ODF, jo mere bliver jeg overbevist om, at englænderne har vist vejen frem.

  • 5
  • 1
Jesper Lund Stocholm

Nu har de jo valgt ODF som dokumentformat, så kan det vel være ligemeget om deres kontorpakke har ringe eller slet ingen understøttelse af OOXML.


Jeps - og derfor stod det også i parentes.

Da kun, hvis Microsoft Office giver en bedre oplevelse med ODF dokumenter.


Nej, for det er ikke Microsoft Office, der er problemet - det er ODF, der er problemet.

De skal naturligvis også vise kausalitet. Og hvis de lugter blot det mindste af "Get the Facts", så vil du blive bedømt negativt på det.


Er du da uenig i konklusionen?

Men det er da pudsigt. Ovenstående tråd er fyldt med udokumenterede påstande om øget konkurrence ved brug af ODF, men det er lige mig, som du afkræver bevis? Du er den eneste, der har brugt "tror" omkring forventningerne til fremtiden med ODF, er faktisk dig (og tak for det) - alle andre har postuleret "ODF medfører øget konkurrence" som var det den guds-benådede sandhed.

Jamen, så må de jo holde sig langt væk fra Microsoft Office.


Igen - det er ikke Microsoft Office, der er problemet. Det er (det manglende) featuresæt i ODF.

  • 0
  • 1
Peter Stricker

Jeps - og derfor stod det også i parentes.


Okay, så vi er enige om, at OOXML support er ligegyldig - i denne kontekst. Og du mener at ODF er et dårligt valg. Det må jeg erklære mig enig i, eftersom jeg er enig med Sune i, at

interchange med det offentlige behøver ikke at supportre kitchen-sink


Valget at ODF skal nok også ses som et fravalg af OOXML, og såfremt det er korrekt, hvad vil du så foreslå?

Nej, for det er ikke Microsoft Office, der er problemet - det er ODF, der er problemet.


Det er din påstand, men fakta er, at de har valgt ODF. De har ikke fravalgt Microsoft Office. Det sidste kan man blot håbe, bliver en naturlig konsekvens. Og du giver da god næring til håbet.

Er du da uenig i konklusionen?


Jeg mener ikke, at den er tilstrækkeligt underbygget. Mange steder, hvor man er gået bort fra Microsoft Office - med München som et af de store eksempler - har der været andre årsager, end valget af dokumentformat. Fornuftigere omgang med offentlige midler har ofte været et argument.

Hvis din påstand er, at interoperabilitet med Microsoft Office via understøttelse af OOXML, er den altoverskyggende årsag til OO/LO's succes, så ja. Den konklusion er jeg uenig i.

Iøvrigt er jeg slet ikke tilfreds med OO/LO's nuværende grad af succes. Jeg ønsker at de får en meget større andel af et forhåbentlig kraftigt faldende merked for kontorpakker.

det er lige mig, som du afkræver bevis


Det er dig, der påstår at et sådant eksisterer. Jeg beder dig blot om at henvise til det.

Igen - det er ikke Microsoft Office, der er problemet. Det er (det manglende) featuresæt i ODF.


Og igen må vi forholde os til den foreliggende situation. ODF er valgt - MSO er ikke fravalgt.

Men hvad er det, du mangler i ODF? Jeg går ud fra, at du mener, at der er mangler i ODF's featuresæt; ikke at det er helt fraværende.

Du har tidligere nævnt versionshistorik. Jeg er ikke enig med dig i, at det er væsentligt at dette er indlejret i det udvekslede dokument. Og det er jo under alle omstændigheder muligt at manipulere med historikken. Hvis man vil have en troværdig diff mellem det afsendte og det modtagede dokument, så bliver man nødt til at sammenligne det modtagede med en gemt kopi af det afsendte.

Er der andre og væsentligere mangler i ODF's featuresæt?

  • 0
  • 0
Jesper Lund Stocholm

Okay, så vi er enige om, at OOXML support er ligegyldig - i denne kontekst.


Jeps.

Valget at ODF skal nok også ses som et fravalg af OOXML, og såfremt det er korrekt, hvad vil du så foreslå?


Det er da at vende tingene på hovedet. UK har tilvalgt ODF. Når jeg nu går ud og siger, at det synes som et uigennemtænkt valg, så bør jeg vel også foreslå et alternativ.

eftersom jeg er enig med Sune i, at "interchange med det offentlige" ...


Men denne afvejning finder blot ikke anvendelse i denne diskussion. ODF er valgt i UK indenfor det offentlige, dvs myndighed-til-myndighed og medarbejder-til-medarbejder. Det er ikke valgt som format i borger-til-myndighed kommunikation.

De skriver selv:

"Government will begin using open formats that will ensure that citizens and people working in government can use the applications that best meet their needs when they are viewing or working on documents together."

Brugsscenarierne er markant forskellige for de to områder. Læg også mærke til, at UK eksplicit nævner "working on documents together".

Hvis din påstand er, at interoperabilitet med Microsoft Office via understøttelse af OOXML, er den altoverskyggende årsag til OO/LO's succes, så ja. Den konklusion er jeg uenig i.


Det har jeg ikke sagt. Jeg har sagt, at den altoverskyggende årsag til OO/LOs succes har været god interoperabilitet med Microsoft Office. Det kan jo ikke være på anden måde. Hvis man ønsker at indtræde på et marked med en 90%-dominans af en anden spiller, så er man nødt til at kunne deltage "problemfrit" i dennes økosystem. OO/LOs success er bygget på god understøttelse af de binære dokumentformater for Microsoft Office. Samme gode understøttelse for OOXML har OO/LO desværre ikke i dag - selvom .DOC og OOXML funktionelt er stort set identiske. Eneste forskel er måden data persisteres på i filen.

Iøvrigt er jeg slet ikke tilfreds med OO/LO's nuværende grad af succes. Jeg ønsker at de får en meget større andel af et forhåbentlig kraftigt faldende merked for kontorpakker.


Det er jeg helt enig med dig i - men det skal ikke ske på bekostning af brugerne (og effektiviteten i det offentlige). Bedre konkurrence giver bedre produkter og lavere priser - dvs flere penge på omsorg/velfærd til borgerne. Historien viser os dog, at dette bedst sker med god interoperabilitet med den dominerende spiller - og denne gode interoperabilitet kan ODF ikke levere (sorry).

Du har tidligere nævnt versionshistorik.


Nej, jeg har sagt ændringsmarkering (tracked changes). Jeg mener, at det er hul i hovedet at vælge et dokumentformat til brug i en redigeringsproces i det offentlige, der ikke kan løfte denne opgave. Uanset hvor meget I piver over dette, så er ændringsmarkering i ODF i bedst fald "utilstrækkelig". Vi kan håbe, at det bliver bedre i ODF 1.3 - hvis de kan blive enige i ODF TC.

ODF er rigtigt godt til mange ting og i de fleste tilfælde (antalsmæssigt) har OOXML ikke noget at lade ODF høre omkring understøttet funktionalitet. Men lige præcist ifht redigeringsprocesser på tværs af brugere har ODF seriøse mangler. Og lige præcist derfor er det uforståeligt at vælge ODF til lige netop denne proces.

Havde valget af ODF været til "borger-til-myndighed-kommunikation", så havde problemet måske været til at overse. Men det er ikke det ODF er valgt til her.

  • 0
  • 1
Peter Stricker

Nej, jeg har sagt ændringsmarkering (tracked changes).


Undskyld, så har jeg misforstået dig. Det skyldes nok, at mit fokus oftest er på sourcekode. Her giver det ingen forskel for mig, om git/cvs/whatever holder styr på versionshistorik, eller om den tracker changes.

Måske er det det oversatte begreb ændringsmarkering, der er årsag til min forvirring. I min begrebsverden er der forskel på at holde styr på forskellige versioner af en fil (persistens), og at vise en diff af forskellene (præsentation).

Jeg kan som bruger være ligeglad[1] med om mit versionshåndteringsværktøj gemmer nye versioner af en fil som et delta af den tidligere version, eller om det altid gemmer den nyeste version som plain text og transformerer den tidligere version til et delta mellem den nyeste og den forrige. Eller om værktøjet vælger at gemme alle versioner af en fil as-is. Eller om strategivalget afhænger af filens beskaffenhed.

Omvendt kan værktøjet være ligeglad med, om jeg vælger at se min diff som ren tekst med plusser og minusser foran ændringer, eller om jeg vælger at bruge et grafisk værktøj til at se ændringerne.

Derfor er jeg lidt usikker på, om ændringsmarkering er en korrekt oversættelse af tracked changes.

[1] Der kan være gode grunde til at foretrække en strategi frem for en anden, men det er ikke funktionelle grunde.

Jeg mener, at det er hul i hovedet at vælge et dokumentformat til brug i en redigeringsproces i det offentlige, der ikke kan løfte denne opgave.


Og jeg mener, med min forståelse af tracked changes, at det er hul i hovedet at indlejre dette i dokumentet.

  • 0
  • 0
Jesper Lund Stocholm

Undskyld, så har jeg misforstået dig. Det skyldes nok, at mit fokus oftest er på sourcekode. Her giver det ingen forskel for mig, om git/cvs/whatever holder styr på versionshistorik, eller om den tracker changes.


Enig :-)

Derfor er jeg lidt usikker på, om ændringsmarkering er en korrekt oversættelse af tracked changes.


Ja, det skal jeg ikke kunne sige - måske jeg bare skal bruge "Tracked changes" fremover. I den danske version af Microsoft Word bruges udtrykket "Registrer ændringer".

http://office.microsoft.com/da-dk/word-help/registrere-aendringer-HA1028...

Og jeg mener, med min forståelse af tracked changes, at det er hul i hovedet at indlejre dette i dokumentet.


OK - men det er (desværre) der, hvor vi er og det er denne funktionalitet, der bruges af kontorpakkebrugerne.

Man kan selvfølgelig sige, at dette burde være gemt på en server etellerandet sted (som fx Google Docs gør det), men hverken ODF eller OOXML (eller deres respektive kontorpakker) er designede ud fra denne betragtning. Dokumenterne er (datamæssigt) "komplette", dvs de kan redigeres uden tab af funktionalitet i offline scenarier.

Om det er optimalt eller ej kan jeg ikke vurdere - men det er sådan det er pt.

  • 0
  • 0
Uffe Seerup

Og jeg mener, med min forståelse af tracked changes, at det er hul i hovedet at indlejre dette i dokumentet.

Jeg tror ikke at hverken OOXML eller ODF har specifikation for integration med versionsstyringsværktøjer (måske Jesper kan hjælpe hér?). Hvis et dokument sendes frem og tilbage mellem medarbejder/medarbejder eller mellem borger/medarbejder, er det ikke sikkert at de har et fælles repository.

Derfor kan jeg alligevel som medforfatter på dokumentet være interesseret i at se ændringer, kommentarer til ændringer mm.

Du er vant til at din kildetekst ikke indeholder ændringer - den er et øjebliksbillede. Men når flere samarbejder om et dokument sker det ofte ved at man aftaler at lave ændringer (fx på møder i en komité) og at en eller flere derefter foretager disse ændringer. Når der senere skal følges op på om beslutningerne er gennemført er det essentielt at de enkelte ændringer kan spores.

Ændringssporingen kan ligge internt som del af dokumentet eller eksternt som historik hvor dokumentet "lever". Jeg tror ikke at hverken OOXML eller ODF specificerer at ændringerne kan lægge eksternt. Det ville jo iøvrigt også fordre, at de samarbejdende parter benytter samme repository.

EDIT: Jeg kan se, at Jesper allerede har besvaret mit spørgsmål: Både ODF og OOXML er "komplette" - dvs at de antager at ændringsmarkering er integreret i dokumentet.

  • 0
  • 0
Peter Stricker

det er (desværre) der, hvor vi er og det er denne funktionalitet, der bruges af kontorpakkebrugerne.


Jeg går så ud fra, jævnfør din kritik af ODF < 1.3, at det afhænger af det valgte dokumentformat?

Om det er optimalt eller ej kan jeg ikke vurdere


Jeg kan heller ikke gøre mig til dommer over om det er den bedste løsning (og lad os så glemme, at vi begge har brugt udtrykket "hul i hovedet"). Men optimalt er det i hvert fald ikke. Ved at have versionshistorikken indlejret i dokumentet, skaber du en situation hvor du kun kan have pessimistic file locking. Jeg kan sagtens forestille mig, at der kan være situationer hvor flere personer kan have brug for at redigere samme dokument på samme tid.

Dette er selvfølgelig med forbehold for, om der rent faktisk er indbygget datastrukturer i OOXML eller ODF > 1.2, der faciliterer optimistic file locking.

  • 0
  • 0
Jesper Lund Stocholm

Jeg går så ud fra, jævnfør din kritik af ODF < 1.3, at det afhænger af det valgte dokumentformat?


Der er i hvert fald en verden til forskel på de ændringer som de to formater understøtter registrering af.

Som Lars fra Norge skrev:

For ODF:

The handling of change tracking in running text is quite fair, but doesn't seem to be complete. Change tracking in tables, lists, formulas, etc is missing.

For OOXML:

OOXML spends 120 pages on this, a lot of them duplicated. The functionality is very detailed, going into table changes, formatting changes, list numbering changes, etc etc. I couldn't digest it all, but as far as I could tell it was solid.

(og Lars er i øvrigt på ingen måde en varm OOXML-fortaler - snarere tvætimod)

Jeg kan sagtens forestille mig, at der kan være situationer hvor flere personer kan have brug for at redigere samme dokument på samme tid.


Det tror jeg også sker relativt tit. Jeg hører i hvert fald ofte om folk, der har skullet flette dokumenter sammen fra flere, der har ændret på samme tid. Det er sjældent en sjov oplevelse :-).

Både Google (Google Docs) og Microsoft (Office 365) understøtter simultan ændring i online dokumenter af flere brugere, men det er deres respektive services, der holder styr på ændringerne - ikke dokumenterne selv (hvis man downloader et dokument fra Office 365, så vil det indeholde markering af alle ændringer indtil "nu" - disse informationer bliver siddende i skyen, hvis man forsøger at gøre det samme med Google Docs).

Dette er selvfølgelig med forbehold for, om der rent faktisk er indbygget datastrukturer i OOXML eller ODF > 1.2, der faciliterer optimistic file locking.


Det er der ikke, og det er heller ikke på tegnebrædtet for ODF 1.3

  • 0
  • 1
Peter Stricker

Jeg tror ikke at hverken OOXML eller ODF har specifikation for integration med versionsstyringsværktøjer


Det er også min opfattelse, at versionering og diff af OOXML og ODF dokumenter er en funktionalitet, der enten er en tillægsfunktion i versionsstyringsværktøjer eller i tredjepartsværktøjer.

Hvis et dokument sendes frem og tilbage mellem medarbejder/medarbejder eller mellem borger/medarbejder, er det ikke sikkert at de har et fælles repository.


Det ville ellers være ideelt, men der er ikke noget til hinder for, at den enkelte medarbejder kan smide alt i sit eget repository. Der er i hvert fald ikke noget i dokumentformaterne eller de største kontorpakker, der forhindrer det. Det vil så selvfølgelig gøre det sværere at afgøre den kanoniske historik, men så findes der andre instanser, der kan tage sig af den slags tvister, hvis de opstår.

Du er vant til at din kildetekst ikke indeholder ændringer


Ja. Jeg er gammel nok til at huske den gang, hvor versionshistorikken var et kommentarfelt i toppen af sourcefilen. Vi er heldigvis kommet videre siden da.

Jeg tror ikke at hverken OOXML eller ODF specificerer at ændringerne kan lægge eksternt.


Det mener jeg heller ikke, at de to dokumentformater skal. Og det tror jeg heller ikke at Jesper mener. Men dokumentformaterne hverken skal eller kan forhindre det.

  • 0
  • 0
Peter Stricker

Mig bekendt er det ikke muligt for nogen af dokumentformaterne at specificere, at ændringer ikke lagres i dokumentet selv


Det var ikke lige det, jeg tænkte på. Men det kunne ellers være smart med en DoNotTrackChanges attribut eller element. Det er jo under alle omstændigheder muligt at slette tracked changes.

Med hensyn til

men på en server


så ville det under alle omstændigheder højst være metadata eller info. Det er selvfølgelig ikke noget, dokumentet har mulighed for at påtvinge. Men informationen kunne dog alligevel være nyttig. Som en slags HvorStammerJegFra info.

  • 0
  • 0
Jesper Lund Stocholm

Det er jo under alle omstændigheder muligt at slette tracked changes.


Måske ser du lidt forkert på "ændringsmarkering". Formålet med ændringsmarkering er ikke kun at kunne identificere, at der er sket en ændring. Formålet er bistå en distribueret redigeringsproces med hjælp til forklaring på, hvorfor dette eller hint er blevet ændret. Så det er altså ikke en manglende feature i ændringsmarkering at man kan slette disse markeringer (svarende til at man digitalt kan signere et brev/dokument og bagefter verificere, om det er blevet ændret). Præmissen for ændringsmarkering er at den sker i en proces baseret på tillid, så der er ikke nogen "Eve" indblandet i Alice og Bobs samarbejde eller nogen ond Bob.

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