Jesper Lund Stocholm bloghoved

Party on like it's 2007

For næsten en æon siden startede polemikken omkring åbne standarder og specielt hvilke vi dog skulle vælge at anbefale i den offentlige sektor i Danmark. På daværende tidspunkt (primo 2007) var der ikke særligt mange (jeg selv inklusive), der havde den store tekniske forståelse for dokumentformaterne ODF og OOXML. Derfor blev debatterne ført på sådan en 'gefühl'-måde, hvor man mere talte på baggrund af mavefornemmelser end reel viden.

Én af de idéer, der opstod dengang var idéen om 'konvertering imellem formater'. Jeg kan ikke huske hvilken IT-ordfører, der først nævnte det, men argumentet var, at man som minimum skulle kunne konvertere imellem de formater, der skulle vælges.

Det lyder som en tilforladelig idé, og den fik da også lov til at stå uimodsagt ganske længe.

Men i takt med, at vi begyndte at få mere 'hands-on' erfaring med dokumentformaterne, begyndte billedet at ændre sig. Specielt i forbindelse med ITSTs pilotprojekter og den tekniske udredning deraf (som CIBER blandt andre deltog i over 14 dage) i efteråret 2007 (altså for to år siden), blev det klart, at idéen om 'konvertering imellem dokumentformater' var en dødssejler. Der var simpelthen for mange steder, hvor selv simple ting som nummererede lister ikke kunne konverteres imellem de to formater. Det blev i hvert fald lysende klart for de af os, der sad i det lille lokale i Høje-Taastrup, at der var nogle meget konkrete ting, der talte imod konvertering imellem dokumentformater.

(at der også er nogle helt grundlæggende ting, der taler imod konvertering er evident. Hvis man kunne omdanne det ene dokumentformat til det andet, så var de to dokumentformater jo reelt ens (sådan matematisk/topologisk set ' tænk på om man putter donut'en i kaffekoppen eller omvendt). Hvis man kunne konvertere med fuld fidelitet, så var de to dokumentformater jo blot repræsentationer af samme format. Dette er på ingen måde tilfældet, og bla. derfor er konvertering ikke givtig)

Jeg kender ingen i dag med teknisk viden om området, der omtaler 'konvertering' som en god idé. Ja, den indsats vi gjorde for at overbevise bla. politikere om netop det problematiske i konvertering, havde faktisk båret frugt, for det er rigtigt længe siden jeg har hørt en IT-ordfører tale om konvertering imellem dokumentformater (liiiige med undtagelse af Morten Messerschmidt, men han er jo sendt langt ned i EU).

Man fristes næsten til at sige 'Mission accomplished'.

Desværre viser det sig nu, at der er én, der ikke har modtaget "notatet" ? og det undrer jo meget, for han har siddet med i udvalget i DS fra dag 1 (indtil for nogle måneder siden). Personen er Morten Kjærsgaard fra Anti-OOXML-leverandørerne (aka OSL). Først var 3. november, hvor Morten Kjærsgaard i Børsen (kræver login) gen-fremførte argumentet om konvertering, da han skrev:

' det [OOXML] kan ikke kommunikere med standardiserede formater som det åbne ODF'

På Version2s lettere tabloide lillesøster Computerworld har Morten Kjærsgaard søreme sin egen blog, og her skrev han d. 6. november:

'Magenta, har (') været med til at udføre de interoperabilitets-tests, der dokumenterer den manglende sammenhæng mellem formaterne. Det spiller simpelthen ikke - og det kommer det næppe nogensinde til.?

Det virker på mig som om, at OSL (og dermed IBM, Sun, ORACLE m.fl.) efterhånden er helt nede i bunden af mølposen efter argumenter imod OOXML. Tilsyneladende er de jo nemlig stoppet med at prædike

  • 'OOXML er et lukket format' ' for det ved vi jo alle godt ikke er sandt
  • 'OOXML er ikke en åben standard' ' for det ved vi jo alle godt ikke er sandt
  • 'OOXML' kan kun implementeres af Microsoft' ' for det ved vi jo alle godt ikke er sandt
  • 'OOXML indeholder proprietære afhængigheder' ? for det ved vi jo alle godt ikke er sandt

Nu har man så fundet en ny vinkel, nemlig at

  • "OOXML kan ikke snakke sammen med ODF"

Men kære Morten ' det ved vi jo alle godt ' og alle vi andre har indset, at det på ingen måde er hverken ønskværdigt eller noget, der nogensinde kommer til at ske. Det var en sympatisk idé i starten, vi opdagede, at den ikke duede, og så kom vi videre i teksten ' og nu skal vi ifølge dig til at snakke om det igen. Du citerer i dit blogindlæg Michael Aastrup Jensen for at have udtalt det i foråret 2008 (for 18 måneder siden) ' men vi er blevet klogere siden da, og det er jeg sikker på, at Michael Aastrup også er. Den eneste der tilsyneladende stadig synes, at det er et vægtigt argument er pudsigt nok ? dig.

Jeg nævnte ovenfor, at

' Jeg kender ingen i dag med teknisk viden om området, der omtaler 'konvertering' som en god idé'

? men måske er det netop derfor, at Morten Kjærsgaard synes, at det er en god idé.

?

Opdatering 12-nov-2009:

Et par links til yderligere kvalificering af "konvertering":

Rob Weir (An antic disposition)
Jesper Lund Stocholm (a mooh point)

Kommentarer (58)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#3 Maciej Szeliga

...som en numreret liste gøres så kompiceret så det ikke kan oversættes ??

...men det kan vel ikke overraske at hvis man ikke engang kan konvertere fra transitional til strict ( se http://www.version2.dk/artikel/12518-isoiec29500-12008-standarden-ingen-... ) så er konverteringer til helt andre formater også problematiske.

Helt ærligt Jesper, tror du ikke selv at modstanden mod OOXML ville falde til et minimum hvis man droppede transitional (og binær) og fokuserede på strict ? Hvorfor støtte et midlertidigt format bare fordi Microsoft tilfældigvis ikke har lyst til at implementere strict med det samme ?

  • 0
  • 0
#4 Peter Stricker

”OOXML” kan kun implementeres af Microsoft” … for det ved vi jo alle godt ikke er sandt

Joh, men de er da igang med at implementere det. Er det ikke omkring 2017 at de får det implementeret ifølge deres egne udtalelser?

En halv snes år efter at B103 blev fremsat.

  • 0
  • 0
#5 Deleted User

tror du ikke selv at modstanden mod OOXML ville falde til et minimum hvis man droppede transitional (og binær) og fokuserede på strict ?

Var man ikke nået til den konklusion at Trasitional var det bedste format, og så droppe alle tanker om de 2 andre?

Jeg savner forresten en opsummering af den research der er blevet foretaget de sidste 2 år, måske specielt kerne kritik punkterne for begge formater. Er de tilgængelig et sted? (Må indrømme jeg ikke har ledt grundigt)

  • 0
  • 0
#6 Jesper Lund Stocholm Blogger

Hej Morten,

Ommer?

Jeg går da netop efter Mortens udtalelser. Hvis du tænker på den sidste linie i artiklen, så er det bestemt ikke nogen hemmelighed, at Morten ikke er tekniker.

Men for at fokusere på artiklen - er du enig med Morten?

  • 0
  • 0
#8 Anonym

Det er så her jeg plejer at komme med en kommentar vedr. det politiske og økonomiske aspekt mht. til valg af teknisk løsning.

En vinkel som du, Jesper, derefter slæber gennem tekniske standard snirkel-kroge.

Det vil jeg undlade denne gang, og istedet læne mig tilbage, smile og glæde mig inderligt over det kæmpeselvmål Microsoft har præsteret på det seneste.

Jeg vil også glæde mig over, at der i de politiske kredse endelig ser ud til, at være fokus på snusfornuftige løsninger, specielt mht. til anvendelse af kontorpakker i folkeskolen.

Det er en skøn tid vi lever i !

  • 0
  • 0
#9 Jesper Lund Stocholm Blogger

Hej Maceij,

...som en numreret liste gøres så kompiceret så det ikke kan oversættes ??

Der er forskelle både ifht formatteringsmuligheder samt måden niveau-inddeling fungerer på (så vidt jeg husker)

Helt ærligt Jesper, tror du ikke selv at modstanden mod OOXML ville falde til et minimum hvis man droppede transitional (og binær) og fokuserede på strict ?

Jo - og hvis du følger lidt med i, hvad vi laver i WG4, så er det noget vi snakker rigtigt meget om i øjeblikket

Hvorfor støtte et midlertidigt format bare fordi Microsoft tilfældigvis ikke har lyst til at implementere strict med det samme ?

Release-cyklussen for Microsoft Office har reelt gjort det fuldstændigt urealistisk at tro, at Microsoft kunne implementere fuld/ren S siden OOXML blev publiceret i november sidste år. Så indtil det sker har vi i mine øjne brug for trods alt at anvende T.

Da DIS-processen kørte virkede det på mange som, at processen var absolut sidste chance for at gøre noget ved OOXML. Men realiteterne er jo, at DIS-processen kun var første skridt i arbejdet med OOXML.

På tilsvarende vis ser jeg modstanden imod at anbefale T. Det er som om, at "I" tror, at i det øjeblik vi anbefaler T, så kan vi aldrig komme væk fra den igen. Denne idé er jeg uenig i. Anbefaling af T er blot første skridt på vejen imod S.

  • 0
  • 0
#11 Jarle Knudsen

Release-cyklussen for Microsoft Office har reelt gjort det fuldstændigt urealistisk at tro, at Microsoft kunne implementere fuld/ren S siden OOXML blev publiceret i november sidste år. Så indtil det sker har vi i mine øjne brug for trods alt at anvende T.

Stop lige her. Jeg husker MS implementerede ODF på nogle måneder og nu kan de ikke implementere deres egen OOXML i over et år?

Hvis det er så svært for Microsoft, vil det være næsten umulig opgave for små og mellemstore aktører.

Vi har talt om kompleksiteten tidligere hvor du har argumenteret det modsatte. Her kommer du med et entydig bevis på at mine postulater var korrekte: [b]OOXML er for kompleks og burde droppes helt.[/b]

  • 0
  • 0
#12 Poul-Henning Kamp Blogger

Stop lige her. Jeg husker MS implementerede ODF på nogle måneder og nu kan de ikke implementere deres egen OOXML i over et år?

Lad os sætte nogle måneder til 3 for at få noget at regne med.

OOXML er 10 gange større end ODF, så det bliver 30 måneder hvilket er 2.5 år.

Nej, jeg tror faktisk ikke at Microsoft kan levere en OOXML strict af en anvendelig kvalitet meget hurtigere.

Poul-Henning

  • 0
  • 0
#14 Jesper Lund Stocholm Blogger

Hej Lars,

Er det bemeldte notat om umuligheden af konvertering offentligt tilgængeligt noget sted ?

Det er ikke et konkret notat som sådan (jeg skulle nok have skrevet det i citationstegn) men blot ganske velkendt viden. Du kan finde det i bla. dokumentationen for ODF-Converter på http://odf-converter.sourceforge.net/, hvor der et eller andet sted findes en oversigt over inkompatibiliteter imellem ODF og OOXML.

Microsoft har også beskrevet nogle af udfordringerne på Doug Mahugs blog på

http://blogs.msdn.com/dmahugh/archive/2008/08/05/guiding-principles-for-...

  • 0
  • 0
#15 Jesper Lund Stocholm Blogger

Hej Peter,

Nej! Men Jesper har pludselig fundet ud af at fuld implementering af OOXML ikke kommer til at ske foreløbig, og så må man nøjes med Transitional.

Jeg synes nu, at der er en fejlagtig udlægning af mine ord - men det er helt korrekt, at jeg ikke før nu havde indset konsekvenserne af kun at anbefale S.

Alternativet er jo helt at droppe OOXML som Jesper nu har kæmpet indædt for i et par år.

Ja, og netop en anbefaling af S er jo i mine øjne nøjagtig det samme som at "droppe OOXML".

Når det så er sagt, så er spørgsmålet om godkendelse af OOXML i Danmark jo reelt fuldstændigt koblet fra mit og CIBERs arbejde i ISO, så jeg overlever nok.

:o)

  • 0
  • 0
#18 Jesper Lund Stocholm Blogger

Hej Lars,

Kunne du kort skitsere umulighederne ?

Der er da nogle ting, der springer i øjnene:

Grafikformaterne er inkompatible Justering er inkompatibelt Forankring er inkompatibelt Nummererede lister (egenskaberne ved dem) er inkompatible Ændringssporing er inkompatibelt Sidefod/hoved er inkompatible (iht fx ændret udseende på første side, så vidt jeg husker) Formel-specifikation er inkompatibelt Dato-systemer er inkompatible

På alle ovenstående områder er der naturligvis overlap, hvor der er kompatible områder (eksempelvis kan simple tegninger relativt enkelt oversættes) - men der er ikke fuld kompatibilitet ved nogen af dem.

Udover listen ovenfor er der en masse mere avancerede ting som digitale signaturer, pivottabeller i regneark [0], kryptering af dokumenter, felt-funktionalitet, CustomXML, DublinCore-egenskaber og andet, der ikke er helt kompatibelt.

At noget står på listen ovenfor er ikke ensbetydende med, at det ikke findes i enten det ene eller det andet format - det kan blot være, at der er dele som fx i DublinCore-implementeringen i OOXML, der ikke findes i ODF.

[0] Jeg faldt over denne - jeg skal ikke kunne sige, om det stadig er tilfældet: http://www.linuxtopia.org/online_books/office_guides/microsoft_office_to...

  • 0
  • 0
#22 Maciej Szeliga

Hej Jesper

På tilsvarende vis ser jeg modstanden imod at anbefale T. Det er som om, at "I" tror, at i det øjeblik vi anbefaler T, så kan vi aldrig komme væk fra den igen. Denne idé er jeg uenig i. Anbefaling af T er blot første skridt på vejen imod S.

Jeg er ikke imod fordi jeg tror at vi aldrig kommer derfra igen, jeg har været i IT så længe at jeg ved at intet varer evigt. Jeg syntes bare at T er spild af tid hvis den kun er midlertidig, den vil betyde at vi får en masse "ukonverterbare" T dokumenter.

I øvrigt er rigtigt mange modstandere i samme aldersgruppe som mig eller ældre så deres modstand er næppe drevet af en naiv tro at man ikke kan komme væk igen.

Lidt OT... og alligevel ikke helt: I øvrigt mener jeg at IT har et meget seriøst problem med langtidsholdbare dataformater: som det ser ud lige nu er det eneste som man med sikkerhed kan læse om 100 år er det som er på papir. Det er lidt pinligt at vi ikke kan slå en 500 år gammel teknologi.

  • 0
  • 0
#23 Lars Ole Belhage

Et par kommentarer:

"Legacy" - selvom OOXML jo er virtuel legacy - altså i 2016-2020 (?)

WG5 i SC34 - så du har faktisk et link vi kan se ?

Og til Maciej - kan vi gange med en 10-1000 stykker, vi kan stadig læse hulemalerier (men nogen kan det være svært at forstå indholdet - ligesom med kommentarer til blogs ;) ) - iøvrigt kan man sige at oldtiden havde en genial "format-konverter" - Rosetta Stenen)

  • 0
  • 0
#24 Jesper Lund Stocholm Blogger

Hej Lars,

WG5 i SC34 - så du har faktisk et link vi kan se ?

Jeg er ikke selv aktiv i WG5, men så vidt jeg kan huske, har IBMs repræsentant i dokumentformatudvalget i DS deltaget i nogle af arbejdsgruppemøderne. Du kan evt prøve at kontakte ham for yderligere information.

Men én af hovedresourcerne i WG5 er DIN/Frauenhofer, og på deres hjemmeside kan du læse lidt mere:

http://www.fokus.fraunhofer.de/de/elan/projekte/national/archiv/ueberset... .

Deres kontaktperson er Klaus-Peter Eckert.

http://www.fokus.fraunhofer.de/de/elan/kontakt/mitarbeiter/_eckert_klaus...

Jeg har opdateret selve artiklen med links til artikler på min egen blog samt Rob Weirs, der omtaler netop konvertering og problemerne med det.

  • 0
  • 0
#27 Thomas Alexander Frederiksen

Jeg har tidligere slået mine folder indenfor arkæologien, og hvis ikke det er lavet om indenfor de sidste fem år, så er det fortsat kun blyant på syrefrit papir der er godkendt til ting der skal langtidsopbevares.

For 50-60 år siden blev der ganske vist gjort forsøg med forskellige typer blæk til kuglepenne, men det er svært at sige hvordan det er faldet ud - der er ikke noget af det der kan læses længere.

Som jeg ser det er et format der ikke nogenlunde smertefrit kan konverteres til/fra præcis lige så anvendeligt som kuglepensforsøgt viste sig at være i det lange løb. Med andre ord må OOXML-T i hvert fald være ubrugeligt, og OOXML-S heller ikke for heldigt - eller?

  • 0
  • 0
#28 Jesper Lund Stocholm Blogger

Hej Thomas,

Som jeg ser det er et format der ikke nogenlunde smertefrit kan konverteres til/fra præcis lige så anvendeligt som kuglepensforsøgt viste sig at være i det lange løb. Med andre ord må OOXML-T i hvert fald være ubrugeligt, og OOXML-S heller ikke for heldigt - eller?

Ja, ovenstående giver så overhovedet ingen mening.

Problemet er ikke, om det er let eller svært at konvertere til/fra OOXML. Problematikken er (sat på spidsen), hvilke problemer det afstedkommer, hvis man ville konvertere et OOXML-dokument til .TXT .

  • 0
  • 0
#29 Henrik Jensen

Jeg er ikke imod fordi jeg tror at vi aldrig kommer derfra igen, jeg har været i IT så længe at jeg ved at intet varer evigt. Jeg syntes bare at T er spild af tid hvis den kun er midlertidig, den vil betyde at vi får en masse "ukonverterbare" T dokumenter

Men det væsentlige skillepunkt er jo at der allerede findes mange dokumenter (flere end nogen anden type dokumenter) som T vil være bagudkompatible med.

Det er klart var det ikke tilfældet så ville det være fuldstændigt og aldeles tåbeligt af have T og man ville aldrig have brugt tid på det i ISO

Det svarer jo til T udgaver af HTML/XHTML. Hvis ikke det var fordi at der allerede var en masse hjemmesider der var kompatible med T så havde det også været absolut tåbeligt ikke kun at have S udgave af HTML/XHTML.

Det ligger vel også i hele ordet "Transitional" at det er en overgang fra noget. Men hvis der ikke er noget eksisterende, så er der jo ikke noget at have en overgang fra.

  • 0
  • 0
#30 Dan Mygind

Hej Jesper,

Kan du ikke lige skære det ud i pap for en som følger dokumentformat-diskussionen fra sidelinien?

Hvis det ikke er muligt at konvertere fra ODF til OOXML - - og den anden vej - hvad betyder det så rent praktisk?

Skal alle programmer, der ønsker at kunne læse og skrive dokumenter så implementere både OOXML og ODF-standarden, hvis Danmark fortsat holder fast i dobbeltbeslutningen?

  • 0
  • 0
#31 Jens Christian Damgaard

Jesper

Problemet er ikke, om det er let eller svært at konvertere til/fra OOXML. Problematikken er (sat på spidsen), hvilke problemer det afstedkommer, hvis man ville konvertere et OOXML-dokument til .TXT

I dit oprindelige indlæg skriver du (2 gange):

Jeg kender ingen i dag med teknisk viden om området, der omtaler ”konvertering” som en god idé

Hvordan får du det til at hænge sammen?

  • 0
  • 0
#34 Christian Nobel

Men det væsentlige skillepunkt er jo at der allerede findes mange dokumenter (flere end nogen anden type dokumenter) som T vil være bagudkompatible med.

Det er idioti på første klasse at lave [b]fremtidens dokumentformat[/b] så det tilgodeser [b]en[/b] fabrikants [b]tåbelige historiske formater.[/b]

Der er altså ingen bilfabrikanter mere der leverer biler med håndsving, eller afviservinger osv.

Heudover, hvis det historiske nonsensargument skulle holde, så skulle WordPerfekt og AmiPros formater da også være dækket ind.

Det offentlige skal kræve at der er et og kun et dokumentformat, og det skal være ODF - herfra er det så op til MS at leve op til spillets regler, samt deltage kontruktivt, og hvis de ikke vil det, jamen så kan de bare ikke levere til det offentlige.

/Christian

  • 0
  • 0
#35 Henrik Jensen

Heudover, hvis det historiske nonsensargument skulle holde, så skulle WordPerfekt og AmiPros formater da også være dækket ind.

Situationen er jo den at

  • Hvis man har eksisterende Wordperfect dokumenter og ønske at åbne dem uden tab/med meget begrænset tab så skal man benytte Corel Wordperfect

  • Hvis man har eksisterende StarOffice eller OpenOffice.org XML dokumenter og ønsker at åbne dem uden tab/med meget begrænset tab så skal man benytte StarOffice/OpenOffice.org

  • Hvis man har eksisterende AmiPro dokumenter og ønsker at åbne dem uden tab/med meget begrænset tab så formoder jeg at man skal benytte IBM Lotus Word Pro

  • Hvis man har eksisterende MS Office dokumenter og ønsker at åbne dem uden tab/med meget begrænset tab så skal man p.t. benytte MS Office

Hvis nu fordelingen for ovenstående var 25% til hver og at alle blev benyttet lige meget i dag, så kunne man måske godt sige, jamen så lad os glemme historiske formater og så fred med at mange måske må køre dobbeltdrift af kontorpakker i en årrække fremover fordi at de har historiske dokumenter de ikke kan konvertere.

Men vi kan jo ikke komme uden om at der er sket en mindre skævvridning af markedet så vi snakker langt fra 25% til hver. Det gør at vi interesserer os mere for at hindre lock-in til "gamle" MS Office dokumenter end vi gør for lock-in til de andre nævnte formater/kontorpakker.

  • 0
  • 0
#36 Jarle Knudsen
  • Hvis man har eksisterende MS Office dokumenter og ønsker at åbne dem uden tab/med meget begrænset tab så skal man p.t. benytte MS Office

Err... wrong. I slutten af 2004 var jeg ansvarlig for konvertering af flere tusind Word-filer (v97 og tidligere) til 2k3. De fleste måtte igennem OOo da MS Office nægtede at åbne dem. Så meget for Microsofts "bagundkompatibilitet" i den virkelige verden.

  • 0
  • 0
#37 Henrik Jensen

Err... wrong. I slutten af 2004 var jeg ansvarlig for konvertering af flere tusind Word-filer (v97 og tidligere) til 2k3. De fleste måtte igennem OOo da MS Office nægtede at åbne dem. Så meget for Microsofts "bagundkompatibilitet" i den virkelige verden.

Men det interessant er jo hvad der blev vist i dem og hvorfor at MS nægtede at åbne dem. Det kan jo være at OOo bare slet ikke forsøgte at parse den del som MS Office "brækkede sig over".

Jeg kan godt bikse en lille applikation sammen på kort tid som kan læse de omtalte Word-filer. Jeg kan bare ikke garantere at jeg repræsenterer alt indholdet i dem. Jeg kan faktisk garantere at jeg ikke gør det.

Bagudkompatibilitet er jo mere end blot at kunne åbne filen, selvom jeg giver dig helt ret at det er en meget essentiel forudsætning for overhovedet at kunne tilbyde bagudkompatibilitet.

  • 0
  • 0
#38 Jarle Knudsen

MSO "bræk" var: kan ikke åbnes - ukendt format.

Og det var intet specielt med indholdet, næsten ren tekst med tabeller i nogle tilfælde. Intet fancy.

Tom. CSC har smedet hånklæde i ringen efter næsten 2 måneder forgæves forsøg.

Sjovt at du altid har et svar parat og tror du kan mere end andre uden at vide HVAD problemet var.

  • 0
  • 0
#39 Jesper Lund Stocholm Blogger

Hej Maciej (og andre),

...som en numreret liste gøres så kompiceret så det ikke kan oversættes ??

Jeg har gravet lidt for at finde listen over forskelligheder imellem ODF og OOXML fra ODF-Converters SourceForge projekt. Deres liste er nok det nærmeste vi kommer en autoritativ liste over forskelligheder imellem "ens" features i OOXML og ODF.

Det viser sig, at den oprindelige tekst-liste over forskelligheder er blevet konverteret til deres bug-track system.

Indgangen til det kan ses herfra:

http://odf-converter.sourceforge.net/features.html

Som eksempel på problemet med nummererede lister (det var i stedet punkt-lister, kan jeg se nu), kan ses denne bug:

"Feature: Bullet numbering ODT and DOCX

The bullets of lists available are not the same in OpenOffice and Open XML. The best match has been chosen for each bullet type."

http://sourceforge.net/tracker/?func=detail&aid=2062431&group_id=169337&...

  • 0
  • 0
#40 Christian Nobel
  • Hvis man har eksisterende Wordperfect dokumenter og ønske at åbne dem uden tab/med meget begrænset tab så skal man benytte Corel Wordperfect

  • Hvis man har eksisterende StarOffice eller OpenOffice.org XML dokumenter og ønsker at åbne dem uden tab/med meget begrænset tab så skal man benytte StarOffice/OpenOffice.org

  • Hvis man har eksisterende AmiPro dokumenter og ønsker at åbne dem uden tab/med meget begrænset tab så formoder jeg at man skal benytte IBM Lotus Word Pro

  • Hvis man har eksisterende MS Office dokumenter og ønsker at åbne dem uden tab/med meget begrænset tab så skal man p.t. benytte MS Office

Hvorved du faktisk på elegant vis har lavet bevisførelsen for at OOXML er en fis i en hornlygte.

Og kan vi så ikke snart få puttet den højt besungne bagudkompabilitet op hvor solen aldrig skinner, og så [b]kikke fremad i stedet[/b].

Uagtet hvordan vi vender og drejer den, så er ikke engang MS i stand til at læse egne gamle dokumenter, så hvorfor i alverden skal der unødigt være fyld a'la "save as Word95" eller hvad det nu hedder ind i dokumentformatet?

Altså et dokumentformat for [b]fremtiden[/b] og så ellers lade de forskellige programmer indlæse og konvertere alt det gamle bras, under erkendelse af at det klarer de fleste faktisk ret godt (hovedparten sågar bedre end MS, plus de så også kan læse WP og meget andet), [b]i praksis[/b] med et [b]minimalt tab[/b] af formattering og andet flueknepperi.

Det her drejer sig om [b]fremtiden[/b] og ikke at tilgodese et vendor-lock-in-firmas perverterede forsøg på at vedblive med at lave lock-in ud fra et pseudoåbent dokumentformat.

/Christian

  • 0
  • 0
#43 Jesper Lund Stocholm Blogger

Hej Maciej,

Altså... det lyder nærmest som en joke... ...at man ophøjer udseendet af bullets til en decideret inkompatibilitet.

Eller har jeg misforstået buggen ?

Nej, det lyder det ikke til at du har (misforstået det). Jeg skal lade andre om at vurdere, om det er et stort eller et lille problem, men at buggen er et eksempel på inkompatibilitet er jo uomtvisteligt.

Hvis det så bare var eneste eksempel, men det er jo bestemt ikke tilfældet. Du kan jo selv begynde at bladre i listerne for regneark, tekstdokumenter og præsentationer. Og så er der jo altid de store klumper som grafikformaterne, hvor DrawingML er milevidt OpenDocument Drawing.

  • 0
  • 0
#44 Jesper Lund Stocholm Blogger

Hej Dan,

Kan du ikke lige skære det ud i pap for en som følger dokumentformat-diskussionen fra sidelinien?

Jeg skal da gøre et forsøg :o)

Skal alle programmer, der ønsker at kunne læse og skrive dokumenter så implementere både OOXML og ODF-standarden, hvis Danmark fortsat holder fast i dobbeltbeslutningen?

Jeg forudser, at følgende vil ske:

Der vil være en lang række små-produkter, hvor man vil lave en oversættelse af OOXML <-> ODF. Det er det jeg kalder "fattigmands-interop". Men de store programpakker som OOo, Symphony, Microsoft Office etc vil ikke kunne undgå at skulle implementere "rigtig" understøttelse af "de andres dokumentformat". Derfor vil disse skulle implementere begge formater.

Jeg vil dog også understrege, at ovenstående er totalt løsrevet fra den danske beslutning. Dokumentformaterne er begge til stede i markedet i dag, og det er producenterne af kontorpakker nødt til at forholde sig til - uanset hvad vi ender med at anbefale her i Danmark.

  • 0
  • 0
#45 Jørgen Henningsen

Helt ærligt Jesper... Hvorfor skal vi blive ved med at diskutere disse dokumentstandarder??

Verden går videre og der bliver, som jeg ser det, støt og roligt åbnet op for konkurrencen på markedet for office produkter. Du har jo ret i at en 100% tabsfri konvertering kun er en fantasi, men det er sådan set ligegyldigt. OOXML er jo bare et nyt internt MS office format. Det er tilfældigvis ISO certificeret, men det faktum har jo indtil videre været uden betydning.

Kompatibiliteten mellem officepakker er jo i realiteten sikret igennem udveksling af almindelige doc/xls filer (f.eks. office 97 format). Det fungere helt fint.

  • 0
  • 0
#46 Jesper Lund Stocholm Blogger

Hej Jørgen,

Helt ærligt Jesper... Hvorfor skal vi blive ved med at diskutere disse dokumentstandarder??

Nogle gange bliver jeg selv helt i tvivl også :o)

Verden går videre og der bliver, som jeg ser det, støt og roligt åbnet op for konkurrencen på markedet for office produkter.

Ja - du har fulstændig ret, og eksemplerne på brug af OOo i diverse kommuner er jo eksempler på netop dette. De er jo nemlig eksempler på, at konkurrence allerede nu føres på produkter, pris og features ... og at konkurrencen bliver bedre og bedre. I mine øjne er det grotesk, at man vil føre konkurrencepolitik på dokumentformater.

Du har jo ret i at en 100% tabsfri konvertering kun er en fantasi, men det er sådan set ligegyldigt. OOXML er jo bare et nyt internt MS office format. Det er tilfældigvis ISO certificeret, men det faktum har jo indtil videre været uden betydning.

Ja, den eneste grund til at det i dag har stor betydning at et format er ISO-certificeret er, at ODF-siden var så eminent gode til at bruge det som argument imod OOXML, da den blev sendt til godkendelse.

Kompatibiliteten mellem officepakker er jo i realiteten sikret igennem udveksling af almindelige doc/xls filer (f.eks. office 97 format). Det fungere helt fint.

Ja, måske skulle vi bare vælge det i stedet :o)

  • 0
  • 0
#47 Jesper Lund Stocholm Blogger

Hej Lars,

Ah!, så det var ikke noget der var udarbejdet i ISO-udvalgets regi...

Det lød ellers sådan, med henvisning til ignoranter som ikke havde læst det - virtuelt altså!

Jeg har sgu fundet noget til dig.

WG5 har offentliggjort senest kladde af deres rapport. Det skete efter mødedagene i København i sommer. Du kan gå amok i dokumentet på http://www.itscj.ipsj.or.jp/sc34/open/1236.pdf

:o)

  • 0
  • 0
#52 Jesper Lund Stocholm Blogger

Hej Carsten,

Givetvis, men stadig et ganske godt bud.

Givetvis - men det fortæller til gengæld, at vedkommende, der har sagt de, ikke har nogen relevant domæneviden på området. Derfor er det muligt, at det er "et godt bud", men det er til gengæld så skrupforkert, at det er fuldstændigt ubrugeligt.

Kvaliteten af "buddet" svarer nogenlunde til kvaliteten af svarene i en Vox-Pop.

  • 0
  • 0
#54 Jesper Lund Stocholm Blogger

Hej Carsten,

Hvad er dit bud, Jesper?

Ingen anelse om størrelsesordnerne, men det er min klare erfaring, at man når langt længere udelukkende med OOXML-spec i hånden end man gør udelukkende med ODF-spec i hånden.

Det er også min erfaring, at hvis man lavede følgende tanke-eksperiment at man lukkede to grupper af udviklere ind i hver sit rum med enten ODF-spec eller OOXML-spec i hånden med det formål at implementere skidtet, så ville sandsynligheden for at de to programmer generelt kunne tale sammen bagefter være langt højere for OOXML end for ODF.

  • 0
  • 0
#56 Jesper Lund Stocholm Blogger

Hej Carsten,

Så er det da også lidt svært at tage alvorligt, at buddet skulle være 'så skrupforkert, at det er fuldstændigt ubrugeligt.'. Du har ingen anelse...

Det kan du tro jeg har. Jeg har fx kigget så tilpas meget i fx ODF-spec i forbindelse med implementering af formatet, at jeg med sikkerhed ved, at ODF-spec ikke er nok i sig selv. Derfor er det skrupforkert at skalere ifht antal sider eller ifht funktionalitetssammenligninger.

Jeg er sikker på, at det vil tage længere tid at implementere OOXML end ODF - men det skyldes primært, at OOXML funktionelt dækker et større område end ODF og ikke at beskrivelsen af funktionaliteten er 10 gange så stor.

Derudover er der jo også pointen med det, der rent faktisk står i den. Hvis ex. formel-spec skal regnes med, så er sideantallet for ODF på 1300 sider - og så er vi pludseligt "kun" nede på 4 gange så mange sider i OOXML. Hiv MathML oveni, så er vi oppe på 1800 sider, dvs "kun en tredjedel".

  • 0
  • 0
#58 Carsten Sonne

Hej Jesper,

Fair nok. PHK's pointe var også blot at specifikationerne er ca. 10 gange større. At specifikationerne i OOXML er mere detaljeret er jo kun en god ting, hvis det vel og mærke er for at skabe klarhed. Modsat, hvis de 5560 siders specifikationer af "Fundamentals and Markup Language Reference" blot er, som en typisk uddybning, så er skalaringen ift. funktionalitet, og derved tid, jo ikke helt ved siden af.

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