Hvad med at gå efter bolden i stedet for manden?
Eller er argumenterne ved at slippe op?
menu close Teknologiens Mediehus
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
Nu har man så fundet en ny vinkel, nemlig at
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)
Hvad med at gå efter bolden i stedet for manden?
Eller er argumenterne ved at slippe op?
Hvis vi ønsker konkurrence på kontorpakke-markedet, er det åbenlyst at vi ikke skal andvende et dokument-format hvor Microsoft har års forspring og alle andre er bagud.
...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 ?
”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.
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)
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?
Var man ikke nået til den konklusion at Trasitional var det bedste format
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. Alternativet er jo helt at droppe OOXML som Jesper nu har kæmpet indædt for i et par år.
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 !
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.
Er det bemeldte notat om umuligheden af konvertering offentligt tilgængeligt noget sted ?
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]
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
Hej Jarle,
Jeg husker MS implementerede ODF på nogle måneder
MS har ikke implementeret den fulde ODF. De har udelukkende implementeret de dele af ODF, der kunne mappes til funktionalitet allerede eksisterende i Microsoft Office.
I øvrigt - hvor har du tallene omkring "nogle måneder" fra?
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-...
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)
Majeij,
Jeg glemte helt
[b]Jesper skrev[/b] 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
Du kan følge med på http://www.itscj.ipsj.or.jp/sc34/wg4/, hvorfra du også nu kan se vores offentlige mail arkiv tilbage fra "dag 1".
:-)
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å!
Kunne du kort skitsere umulighederne ?
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...
Hej Lars,
Ah!, så det var ikke noget der var udarbejdet i ISO-udvalgets regi...
Dammit ... jeg glemte helt, at WG5 i SC34 arbejder netop med interop imellem dokumentformater samt problematikkerne med det.
Ah, du snakker om OOXML-T vs OOXML-S - så forstår jeg bedre...
Hej Lars,
Ah, du snakker om OOXML-T vs OOXML-S - så forstår jeg bedre...
Nej - når jeg snakker om konvertering ovenfor, så er det ifht ODF og OOXML. Men problemet er jo præcist det samme som imellem "legacy" i T og "det nye" i S. "Problemet" er i øvrigt langt mindre imellem S og T end imellem ODF og OOXML.
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.
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)
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.
Ja, fine links - men du har altså ikke et "notat" (i gåseøjne eller ej) ?
Hej Lars,
men du har altså ikke et "notat" (i gåseøjne eller ej) ?
Nej - min formulering var en fordanskning af det engelske små-ironiske "apparently he didn't get the memo".
Tvivler du på mine ord - eller tror du mig bare ikke over en dørtærskel - hvis du ikke kan få en autoritativ kilde?
:o)
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?
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 .
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.
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?
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?
Jeg kan ikke se problemet?
Sorry
Kom til at forveksle dit indlæg med Henrik Jensens.
Bekagler fjelen. (ku ikke nå at redigere)
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
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.
- 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.
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.
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.
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&...
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
Hej Jesper
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 ?
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.
Cool. Hvilken dimension måler man "større end" i for at få den estimeringsmetode til at virke?
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.
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.
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.
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)
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)
Cool. Hvilken dimension måler man "større end" i for at få den estimeringsmetode til at virke?
Specifikationerne; Med den antagelse at der en 1 til 1 mellem mængden af specifikationer og funktionalitet, og derved antageligvis opgavens størrelse. Det er et ganske godt initialt bud.
Hej Carsten,
Det er et ganske godt initialt bud.
Måske - men til gengæld er det forkert.
Christian Nobel:
Det her drejer sig om fremtiden...
Det beskriver meget godt hvordan præmisserne for diskussionen er helt forkerte. Hvad er det egentlig vi diskuterer? Og hvad er en ønskelig fremtid?
Måske - men til gengæld er det forkert.
Givetvis, men stadig et ganske godt bud.
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.
Hvad er dit bud, Jesper?
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.
Ingen anelse om størrelsesordnerne...
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...
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".
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...
Jesper, du har hermed et nyt punkt til dit CV:
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.
