Der er kun én ting galt med OOXML

OOXML er meget omdiskuteret, blandt andet på version2, også ned i nogle detaljer som er ud over de flestes fatteevne (bl.a. min) eller uden for ens interessefelt (bl.a. mit). Men set fra mit helikopter-perspektiv er der kun én grundliggende ting galt med OOXML:
 
Bagud-kompatibilitet med gamle version af office-produkterne. For hvem har interesse i at kunne læse og gemme i Word 95 format uden tab? Ikke min virksomhed, og heller ikke din, vi konverterer bare de dokumenter som stadig er interessante. En god standard ser fremad i stedet for at omfavne fortiden.

Så vidt jeg kan se, er resten af diskussionen mere eller mindre udsprunget af at standarden er bagud-kompatibel, fx

  • Dens enorme omfang på ca.7000 sider: Noget med det omfang er ikke en standard, men blot en dokumentation af tingenes tilstand i dag uden udeladelser, [som der siges i en kommentar](http://www.version2.dk/artikel/6742#p14486)
  • Tvetydigheder og inkonsistens i et større omfang som følge af implementerings-detajler i de forskellige fortidige versioner
  • Inkonsistens og sjuskefejl som følge af hastværk (7000 sider tager tid at lave...) og som følge af at selv MS måske er faret vild i værket
  • Microsofts besvær med og efterfølgende behov for pres for at få gennemført godkendelsen

Det er rart at betragte fra helikopter-perspektiv ' alt ser så simpelt ud på afstand. Men har jeg ret'

Kommentarer (38)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Michael Rasmussen

Hej Peter,

Du bekræfter blot, hvad jeg har argumenteret for hele tiden. Adskil specifikationen i to dele: En del der vedrører konvertering fra gammelt til nyt - denne del kunne sagtens være closed source eller en binær DLL, samt en del der udelukkende beskriver det fremtidige format.

Var det blevet gjort fra starten af, tror jeg de fleste ville have været kunnet stillet tilfredse, og al diskussionen kunne så have været henlagt til evangelister fra begge lejre. Min personlige vurdering er, at vi ville have haft en væsentligt bedre standard, på et væsentligt antal færre sider, hvilket ville have betydet, at de fleste ville kunne være med!

Christian Nobel

Selvfølgelig har du ret Michael, men dette har på intet tidspunkt været interessant, for står man dybest set med ODF + en konverter.

Og dette passer jo ikke just ind i MS strategi; "One ring to rule them all".

Endvidere skal da heller ikke glemme at huske på at folkene fra Mordor ^^^^^^ ehhh Redmond i 2002, da OASIS oprettede ODF TC, var, som medlem af OASIS, inviteret til at deltage i samarbejdet omkring specifikationen, på samme vilkår som alle andre, men de ville ikke være med!

/Christian

Thorbjørn L_.

Jeg er ikke enig. Den primære ting, der er galt med OOXML er at MS ville have den iso-godkendt - og det burde den aldrig være blevet, da der allerede findes et en ISO-standard for dokumenter nemlig ODF!

Så hvis ISO følger deres (nye) kvalitet-linje kan vi måske få 100 timers døgn (som er nemmere at regne med) og 5 måneders år ...

(Bagudkompatibilitet som skyldes det linære map fra MS binær kode til standarden er selvfølgelig et problem men ikke det primære)

Henrik Jensen

Et lidt andet perspektiv

Først og fremmest kunne det være rart at se en undersøgelse af brug af bagudkompatibilitets settings i Word som involverere mere end din eller min virksomhed og husk på at disse bagudkompatibilitets settings også er tilstede i nyere version af Office, så f.eks. "Auto Space Like Word 95" kan altså også være sat af brugeren af en eller anden årsag i nyere version af Office.

Spørgsmålet er burde Microsoft havde droppet alle disse settings i OOXML? Der er ingen tvivl om at Office bare vokser, vokser og vokser og det samme vil OOXML så længe Office holder liv i og giver brugerne mulighed for at bruge alle disse settings. Så ingen tvivl om at det ville være rart at få ryddet ud i disse settings men spørgsmålet er hvornår det kan gøres, hvor lille procentdel af brugerne skal benytte en funktionalitet før man ofrer dem.

Så hvis vi nu tager helikopter-perspektivet og antager at der rent faktisk er folk der stadig ønsker at bruge disse gammel settings eller at Micrsoft blot ønsker at tilbyde denne funktionalitet så kommer et principielt spørgsmål: Er vi ude i at man af hensyn til standardiseringen skal sætte begræsninger for hvor meget funktionalitet relateret til standarden en implementation må indeholde? Altså begynde at sige at så må der tages funktionalitet ud af vores applikationer så vi bedre kan standardisere deres formatter, og i såfald hvordan skal vi specificere dette?

For dem der mener at standardisering ikke må sætte begræsninger for hvor meget funktionalitet der må placeres i en applikation, så kommer næste spørgsmål så hvordan Microsoft/ECMA skulle havde håndteret dette? Lad os tage "Auto Space Like Word 95" som eksempel. Prøv at læse beskrivelsen af af denne settings adfærd og fortæl mig hvilke eksisterende settings den kunne mappe til? Jeg kan ikke set det.

Så hvis vi nu prøver at antage at denne setting ikke kan mapppes til andre settings og at vi ikke i "standardiseringens tjeneste" kan tvinge applikationer til at droppe funktionalitet, så er vi altså enige om at den skal med. Så ser jeg der er følgende muligheder

1) ECMA/Microsoft kunne så vælge ikke at gøre den en del af OOXML standarden og Microsoft kunne så placere den som egne extension. På samme måde som OpenOffice, KOffice også har supersets (extensions) af ODF. Jeg er sikker på dette ville give stor kritik

2) ECMA/Microsoft kunne vælge at omdøbe så setting fik et andet navn en AutoSpaceLikeWord95, et navn som "lugter" mindre af bagudkompatiblitets-settings. Det er også en mulighed men på den anden side så ændrer navngivningen altså intet ved hvor svært eller nemt det er at implemenetere og understøtte.

3) EMCA/Microsoft kunne vælge at benytte et navn som præcist afspejlede hvilken funktionalitet i Office der var tale om. Så setting hedder AutoSpaceLikeWord95 i standarden og "Auto Space Like Word 95" i Office.

Nu valgte EMCA/Microsoft som nævnt løsning 3 men hvilken løsning synes I de skulle havde valgt?

Det skal forøvrigt nævnes at rent dispositionsmæssigt i DIS29500 så kommer alle disse kompatibilitets settings nu ud i et særskilt dokument hvis ellers jeg har forstået resultatet af ISO-processen korrekt. Disse settings er jo ikke obligatoriske at benytte hvis man ønsker at implementere en office applikation der ikke tilbyder denne funktionalitet.

Så kan man selvfølgelig argumentere for at OOXML er en standard og ikke burde afspejle Office, men husk lige historien:

2000: Microsoft startede med et nyt dokumentformat OOXML (i første omgang kun SpreadsheetXML) da der var stort ønske fra brugeren om at åbne op i forhold til de gamle dokumentformater.

2004: En undersøglesgruppe fra EU anbefaler Microsoft at de overlader deres XML dokumentformater til en standardiseringsorganisation. Undersøgelsesgruppen kiggede også på ODF som var under udarbejdelse i OASIS på dette tidspunkt så de var udemærket klar over at dette alternativ eksisterede

2005: Microsoft sender deres XML dokumentformater til ECMA og de vælger ikke at pille alle deres bagudkompatibilitets settings ud af formaterne før de gør det.

Så når vi har denne historik så efterlader det to spørgsmål

1) Kan vi bebrejde Microsoft at de udarbejdede OOXML så den passede til Office på det tidspunkt hvor de gjorde? Hvis ikke hvorfor så udarbejde OOXML?

2) Hvad var der sket hvis Microsoft havde taget en del settings ud af OOXML og så sendt standarden til ECMA? Havde folk så klappet i deres hænder over denne beslutning eller kritiseret Microsoft?

Der er nok mange der ikke deler mit perspektiv, men i det mindste kan i sagligt overveje ikke mindst det principielle spørgsmål jeg stiller.

Henrik Jensen

Hvis jeg udvider mit principielle spørgsmål fra ovenstående så kan det også benyttes omkring de 2 ISO-standarder. Hvis Microsoft skulle havde benyttet ODF så ser jeg følgende muligheder

1) ODF fik alle disse "herlige" bagudkompatibilitets ting ind i deres format. Ville der overhovedet kunne blive enighed om dette i OASIS? Ville OASIS (Sun/IBM) bare uden videre sidde og hive gamle kompatibilitetsting ind fra Office i ODF?

2) Microsoft blev i "standardiserings tjeneste" tvunget til at hive funktionalitet ud. D.v.s. enten helt ud af Office eller lade dem blive i Office og så fastholde at brugere skulle benytte de binære formater hvis de ville benytte disse funktionaliteter.

3) Microsoft blev bedt om at placere alle deres settings i supersets (extensions) til ODF? Det er selvfølgelig en løsning men er dette ikke også en del af interoperabilitets problemet mellem forskellige ODF implementationer at der er extensions der vedrører den visuelle præsentation?
Det ville da ikke blive bedre af at Microsoft lavede et kæmpe superset.

Hvilken vej synes I de skulle havde valgt eller er der en vej jeg har overset?

Jesper Lund Stocholm Blogger

michael,

Du bekræfter blot, hvad jeg har argumenteret for hele tiden. Adskil specifikationen i to dele: En del der vedrører konvertering fra gammelt til nyt - denne del kunne sagtens være closed source eller en binær DLL, samt en del der udelukkende beskriver det fremtidige format.

I en nøddeskal var det du her nævner jo faktisk ét af de konkrete resultater fra mødet i Geneve.

Vær i øvrigt opmærksom på, at bagudkompatibilitet jo også vedrører simple ting som [b]fed[/b]- og [i]kursiv[/i] skrift.

:o)

Kaspar Lundsby

Henrik Jensen skriver bl.a.:
"Er vi ude i at man af hensyn til standardiseringen skal sætte begræsninger for hvor meget funktionalitet relateret til standarden en implementation må indeholde?"
Skal vi nu ikke holde skidt og snot hver for sig? En dokumentstandard skal vel beskrive, hvad et dokument indeholder og hvordan det skal præsenteres. Hvordan dokumentet produceres må vel være op til den enkelte implementatør af standarden. Applikationsfunktionalitetsbeskrivelse hører ikke til i en dokumentstandard, og endnu mindre beskrivelse af hvordan man bliver kompatibel med legacy-funktionalitet!

"1) Kan vi bebrejde Microsoft at de udarbejdede OOXML så den passede til Office på det tidspunkt hvor de gjorde? Hvis ikke hvorfor så udarbejde OOXML?"
Næh, man kan da på ingen måde bebrejde Microsoft for at gøre forsøget - men man kan bebrejde Dansk Standard m.fl. for at ophøje noget, der ikke burde have været en standard til at være en ISO standard.

"2) Hvad var der sket hvis Microsoft havde taget en del settings ud af OOXML og så sendt standarden til ECMA? Havde folk så klappet i deres hænder over denne beslutning eller kritiseret Microsoft?"
Microsoft vil nok altid blive kritiseret. I denne debat er det nu ikke alene blevet Microsofts produkt, der står for skud, men også Dansk Standards og Microsofts formodede ageren i sagen. Det er for mig at se langt værre, for det er ikke noget, man kan fravælge!

Peter Nørregaard Blogger

Henrik, det er rigtigt rart med et illustrativt eksempel der både går i dybden og forbilledligt klart illustrerer en pointe. Godt gået!

Du spørger "Er vi ude i at man af hensyn til standardiseringen skal sætte begræsninger for hvor meget funktionalitet relateret til standarden en implementation må indeholde?"

Mit bud er klart: Ja, det er vi, hvis produktet kun ønsker kunne forstå en standard og ikke har sit eget format.

David Konrad

OOXML er skam fint nok som format. Måske er det det mest seriøse forsøg på at formalisere avanceret indhold af dokumenter overhovedet.

Det som er hovedproblemet er målsætningen :

"The goal is to enable the implementation of the Office Open XML formats by the widest set of tools and platforms, fostering interoperability across office productivity applications and line-of-business systems, as well as to support and strengthen document archival and preservation, all in a way that is fully compatible with the large existing investments in Microsoft Office documents"

Læg mærke til den sidste sætning.

Kilde (eksempelvis) http://www.ecma-international.org/memento/TC45.htm

  • Altså, det erklærede formål med OOXML er alene og udelukkende at sætte tredjeparts programmel i stand til at kunne læse og skrive MS Office-dokumenter, ikke omvendt. Ikke at gemme og læse filer generelt, men filer fabrikeret af og til MSO alene. OOXML skal være kompatibelt med MSO - MSO skal ikke følge evt ændringer i OOXML, som andre kunne finde på. Formatet (og ISOficeringen) har til hensigt at gøre MSO til officiel de facto standard, og andre som slavebrugere af denne standard, samt MSO-programsuiten - uanset platform, sprog og omfanget af anvendelse.
Henrik Jensen

.....forsat fra tidligere

Hvis nu der bliver enighed om at der skal være en grænse for størrelsen af standarder så kommer så det næste spørgsmål så hvordan vi definerer det og hvordan vi fravælger. Jeg har gjort mig lidt tanker, men det er ikke let.

Med hensyn til størrelsen så kunne et par muligheder være

1) Baseret på sideantal alene, altså en standard må aldrig være over f.eks. 2000 sider. Hvad skal sideantallet være og hvordan forholder vi os til ting som f.eks. eksempler, illustrationer m.v.? Jeg mener hvis samtlige eksempler + illustrationer blev hevet ud af OOXML så var de første i hvert fald mindst 1000 sider sparet men det har reelt intet ændret på hvad der skal implementeres. Hvordan forholder vi os til referencer til andre standarder? Jeg mener hvis der står "This behaves like xxx in yyy" hvor yyy er en anden standard, så er det selvfølgelig kort og fylder ikke meget, men det betyder jo ikke nødvendigvis at man slipper for at hoppe over i yyy og læse der også. Summerer man siderne i alle standarderne? Samtidigt skal vi jo også passe på at der ikke optimeres for meget for at komme under 2000 sider, jeg mener en fuldstændigt underspecificeret standard kan ikke vi jo heller ikke bruge til noget.

2) En anden mulighed var at se på de implementationer der faktisk er og om de magter at implementere den fulde standard. Lad os tage ISO C++ standarden den er jo reelt kun små 800 sider (så den vil altså ikke falde for max. 2000 siders kravet) i nuværende version men stadig stor/kompleks nok til at mange implementationer kun er subset af den fulde standard. Denne metode er også en mulighed men den er svær at benytte for helt nye standarder, og hvordan sikrer man sig at konkurrenter ikke ødelægger det for andre ved med fuldt overlæg at udvikle implementationer som kun er subset?

Dette er blot 2 muligheder men ingen af dem er perfekte synes jeg. Hvordan synes I det bør afgøres op om en standard er for stor?

Det andet er hvad skal man så gøre hvis man står med en standard der er blevet for stor som f.eks. OOXML og måske C++, hvordan vælger man hvad der skal droppes. Umiddelbart synes jeg at det ville være mest korrekt at droppe det der benyttes mindst, men når jeg så tænker over det så har denne fremgangsmåde alligevel sine problemer. Lad mig give et par eksempler

1) Først og fremmest så er der jo hele spørgsmålet omkring om 'mindst' overhovedet er fornuftigt. Jeg mener der er jo forskel på at finde ud af at den mindst benyttede funktionalitet (relateret til standarden) den benyttes af 10% af brugerne eller kun 0.1%. Jeg mener hvis vi begynder at tvinge elementer ud af standarder som 10% benytter og så vil tvinge de selvsamme folk til kun at benytte åbne standarder når de kommunikerer med det offentlige, så er vi jo ikke spor bedre end dem som designer offentlige hjemmesider der kun virker i Internet Explorer og er ligeglad med de sidste n%.

2) Så er der problematikken med at nogle elementer i standarden måske benyttes af meget få men tilgengæld er meget vigtige for de få. Lad os sige at man sammenligner en indstilling som AutoSpaceLikeWord95 (altså en legacy setting) og så en indstilling (eller evt. bare alle 'alt' attributer på shapes) som kun benyttes af tilgængelighedsværktøjer til gavn for blinde og svagtseende. Hvad nu hvis det viser sig at 1% stadig benytter AutoSpaceLikeWord95 men kun 0.2% benytter 'alt' attributter på shapes, jeg mener så mange bilnde + svagtseende er der jo heller ikke. Skal 'alt' attributten på shapes så bare droppes?

Risikerer vi ikke at når standarderne når grænsen for hvor store de må være og hvis flertallet af brugerne ønsker ny funktionalitet så dropper man bare alt hvad der er af tilgængelighed og så kan folk med funktionsnedsættelse bare.... lave deres egne standarder?

3) Der er også en problematik der gør at man måske skal vægte elementer i standarden ud fra om der er rimelige alternativer. Hvis vi tager ISO C++ som eksempel, hvad nu hvis man fandt ud det mindst benyttede var GetSystemTime med 1% og While løkker med 2% (meget tænkte eksempler - ved det godt) så ville det umiddelbart være mest fornuftigt at smide GetSystemTime væk. Men på den anden side så kunne man jo også argumentere for at While løkker havde nogle rimelige alternativer i For og Do løkker så måske skulle man smide While løkker væk i stedet?

4) Så er der hele problematikken med indkøringsperioder. Jeg mener i 2009 skulle der gerne komme en ny ISO C++ og der vil selvfølgelig være nogle nye elementer i standarden. Hvis man lavede en undersøgelse umiddelbart efter så ville det jo nok vise sig at nogle af de mindst benytte elemener i ISO C++ det var de nytilkomne, men det virker jo ikke helt klogt derfor blot at smide dem ud igen med det samme. Man kunne selvfølgelig klare det ved at sige at man først må tage noget ud før der kan komme nyt ind men hvordan vurderer man så om der vil være flere brugere af de nye elementer en de gamle der tages ud? En anden mulighed var at give et nyt element i standarden en indkøringsperiode hvor den ikke kan "stemmes ud igen" for at give den en reel mulighed for at blive taget i brug.

Endnu et langt indlæg fra min side og I vil sikkert undre jer hvorfor og grine lidt af nogle af tankerne eller se det som en provokation.... det er det nok også lidt. Jeg ser utroligt mange indlæg som er 3-4 linier hvor der leveres en sviner af Microsoft, OOXML, ISO-processen o.s.v. (og bestemt også den anden vej rundt mod Open Source, Linux etc) og måske lige krydret med et eller andet udsagn som "OOXML er alt for stort", "Man skal bare fjerne funktionalitet for Office", "ISO-processen er til grin" etc.

Så det er måske lidt en provokation for at se hvor mange der er villige til at gå udover de 3-4 liniers ukonstruktive udsagn og så faktisk tænke lidt dybere konstruktivt over problematikken og hvad der kan gøres for at gøre standardiseringsarbejdet bedre. Det er utrolig nemt at komme med et udsagn om at noget bør der gøres og så sætte sig ned og vente på at alle andre gør det hårde arbejde og tænker alle de store tanker (nu hentyder jeg ikke til mine egne små ovenstående tanker)

Thorbjørn L_.

citat:
"Ville OASIS (Sun/IBM) bare uden videre sidde og hive gamle kompatibilitetsting ind fra Office i ODF?"

Umiddelbart tror jeg at ODF har bedre justerbare primitiver. (Dermed forestiller jeg mig at mange af bagudkompatibilitetstags OOXML har kan laves af justerbare ODF-tags - For ellers ville den vel ikke kunne konvertere .doc til odf dokumenter ordentligt... ). Det er dog et ræsonnement - ikke noget jeg er sikker på ...

Ovenstående argument er dog ikke specielt vigtigt.
Det, der er vigtigt er at MS overhovedet ikke ville snakke med OASIS - og fremsætte krav / ønsker.
For det MS ønsker at bevare sit monopol og lægge ODF i graven. De ønsker ikke at der findes et fælles format som fungerer alle steder...

Dermed er dine hypotese spørgmål om hvad MS skulle have gjort ikke specielt interessante - for det MS skulle have gjort - såfremt de havde ønsket en fælles standard - var jo i det midste at forhandle med OASIS.

Jeg deler konkurrenterne bekymring ...
http://www.comon.dk/index.php/news/show/id=35481

Henrik Jensen

Kan den konvertere DOC til ODF dokumenter ordentligt?, hvordan definerer du så ordentligt?

ODF har en 'text-autospace' attribut på paragraphs som kan være 'none' eller 'ideograph-alpha'. Men jeg mangler en 'ideograph-alpha-in-the-stupid-wrong-way-that-microsoft-word-95-did-it'
mulighed. Hvis vi tager AutoSpaceLikeWord95 som eksempel så er den jo netop en legacy setting fordi at man implementerede autospace forkert i Word 95. Det betyder også skulle man havde den ind i ODF så var det ikke nok at angive at man havde denne ektra mulighed man skulle også grundigt beskrive den, da det jo netop er en forkert implementation. Ellers ville det jo stå folk frit for hvordan de implementerede den forkert igen og så er vi jo lige vidt.

Det betyder også at det forhåbentligt er et absolut fåtal der benytter denne legacy setting, da man på alle nye dokumenter burde benytte den korrekte metode, som altså kan mappes mellem ODF og OOXML.

Hvorfor så ikke bare fjerne AutoSpaceLikeWord95 i OOXML? Problemet er at der jo ligger en del dokumenter der benytter denne type spacing upåagtet at den er forkert, og der kan være behov for at disse dokumenter kan føres videre med 100% præsentations nøjagtighed. Det kan f.eks. i juridiske sammenhænge men det kan også være direkte farligt!!!

Nu håber jeg ikke du fik noget galt i halsen med den udmelding, jeg siger med et meget stort grin på læberne mens jeg siger "farlig!!!"

Lad mig citere den ekspertgruppe som i 2004 i EU kiggede på forskellige dokumentformater

"Documents can lose meaning or value if the layout or visual emphasis is altered. In legal or regulated environments, retaining fidelity may be a requirement for official communications or legally binding transactions.

Lack of presentation fidelity could also have dangerous effects. On June 27, 1988, a train crashed into the Gare de Lyon in Paris at high speed and without braking. More than fifty people were killed in the accident and considerable number wounded. The accident was found to be caused by the coincidence of two badly formatted indented instructions in the maintenance manual"

For lige hurtigt at præcisere så griner jeg bestemt ikke af det der faktisk skete, for det er selvfølgelig tragisk, men jeg griner af årsagen til at det skete.

Men der er alligevel noget sandhed i det, men jeg synes pointen omkring juridiske dokumenter er langt vigtigere for der er man altså nogle steder meget konservative. Jeg er f.eks. uheldigvis rodet ind i et civilt søgsmål i Indien og i Delhi High Court har de nogle juridiske dokumenter der skal underskrives som kun findes i 'Legal' størrelse. Denne størrelse er jo næsten samme størrelse som A4 men der er alligevel en lille forskel. Papir i Legal størrelsen kunne jeg ikke opdrive i Danmark og jeg kunne ikke få lov at printe på A4 da dels papirstørrelsen var forkert og dels så kunne teksten rykke sig fordi at der var forskel på størrelsen. Resultat = Min advokat i Indien printer og sender med DHL og jeg underskriver så og sender tilbage med DHL og må så betale 2x DHL.

Så selv om det for langt langt de fleste af os ikke betyder så meget om præsentationen er 100% ens men kan nøjes med 99.5% hvis bare indholdet er det samme så har det altså betydning for nogen... husk også hvordan begrebet "Pixel Perfect" ofte kommer i tale når der snakkes hjemmesider/html/forskellige browsere.

Omkring 100% præsentations nøjagtighed så kunne man selvfølgelig havde taget andre veje end Microsoft har gjort. Jeg har f.eks. set ODF alliancen foreslå at man i stedet bare måtte lade brugere blive ved med at benytte Word 95 og .doc hvis de havde dette behov da det også er eneste måde man 100% kan garantere præsentations nøjagtighed (Microsoft kan jo lave fejl imellem versioner af Office). Det er også en mulighed men det det fremmer jo ikke åbenheden at vi skal tvinge nogle folk til at blive ved med at benytte .doc og det fremmer heller ikke muligheden for at de kan vælge alternativer til Microsoft.

Nu forudser jeg at nogle så vil sige "Microsoft lavede fejl med vilje for at kunne fastholde deres brugere".... først og fremmest så ville det da være klogere at holde AutoSpaceLikeWord95 for sig selv og ikke inkludere den i standarden så, men noget helt andet er hvordan tror I selv det vil se ud for OpenOffice, KOffice, Google Docs o.s.v. om 5-10 år hvis de ikke meget hurtigt får løst de interoperabilitets problemer der er mellem forskellige implementationer af ODF?

Hvis de forskellige implementationer af ODF ikke har 100% præsentations nøjagtighed så på et eller andet tidspunkt så må en eller flere af implementationer bide i græsset og acceptere at de har fortolket eller implementeret standarden forkert. Hvis de har et tilstrækkeligt stort antal brugere der allerede har benyttet værktøjet og udarbejdet dokumenter med den forkerte implementationen så bliver de nødt til at bibeholde en kompatibilitets setting. Så kommer valget skal denne kompatibilitets setting ind i ODF standarden eller skal den være applikations specik. Hvis man smider dem ind i ODF standarden så begynder man over tid at få samme "uskønne" standard som OOXML, hvis man ikke smider dem ind så kan man ikke sikre interoperabilitet mellem de forskellige ODF implementationer hvilket fører til vendor lock-in. Ikke nogen nem beslutning, men jeg foretrækker altså personligt førstnævnte mulighed, da hele begrundelsen i den første omgang for at havde en standard er et sikre bedre interoperabilitet og undgå vendor lock-in.

Hvis man kigger så har OpenOffice jo allerede nu en række applikations specifikke udvidelser til ODF som har at gøre med præsentationen. Jeg ved ikke om de er der af hensyn til bagudkompatibilitet eller ej. Men faktum er at ønsker KOffice, Google Docs etc. at vise at ODF dokument der kommer fra OpenOffice og har benyttet de pågældende applikations specifikke udvidelser, så kan de ikke vise med 100% nøjagtighed ud fra ODF standarden men må ind og kigge i kildekoden for OpenOffice for at finde ud af hvordan det skal implementeres. (og det gælder selvfølgelig også anden vej rundt, KOffice har f.eks. også applikationsspecifikke udvidelser til ODF)

Jeg tror kort fortalt skal man bare være realistiske og så acceptere at det er de færreste ting i vores branche der er 100% perfekte og så arbejde konstruktivt ud fra dette.

Det betyder også at man nogle gange bare må acceptere historiens gang. Jeg siger ikke at man ikke stadig godt må være af den mening at Microsoft "bare" skulle havde skiftet OOXML ud med ODF men man kan faktisk godt havde den mening og så SAMTIDIGT arbejde konstruktivt ud fra den nuværende situation. Det svarer lidt til at man godt generelt kan være af den mening at Danmark ikke bør være medlem af EU men derfor kan man godt samtidigt se konstruktivt på det samarbejde vi nu engang har i EU når nu situationen er som den er.

Jeg synes Patrick Durusau, som jo er betalt af Sun for hans arbejde på ODF standarden i Oasis regí siger det så smukt når han bliver spurgt hvorfor i alhverden en mand i hans position ønsker ISO godkendelsen af OOXML velkommen, mener at der skal ses på hvordan ODF, OOXML, UOF og PDF/A kan sameksistere bedst muligt o.s.v.

"The difficulties we face today are the result of not talking to each other in the past and we can't change the past"

Han har den rette forståelse (efter min mening) for hvad det vil sige stadig at være grundlæggende imod hvad der historisk er sket, men stadig fokusere på et se konstruktivt fremad ud fra den nutidige situation.

Jens Fallesen

Blogskribenten har jo fuldkommen ret, når han påpeger det vanvittige i, at standarden skal være bagudkompatibel.

Hvorfor skal der være en ISO-standard, der er bagudkompatibel med Microsoft Office?

Hvad så med Corel/WordPerfect Office, Lotus SmartSuite, Frameworks og andre officepakker? Skal alle disse også være en del af OOXML, eller skal der ende med at være massevis af inkompatible ISO-standarder for dokumenter?

Verden vinder ikke noget ved, at der står ISO på en række dokumentformater i stedet for en række leverandørers navne.

Jesper Lund Stocholm Blogger

Eskild,

JLS - du har selv gjort opmærksom på at kompatibiulitetssettings stadig var en del af standarden, selvom de nu er i et annex.

Det var også hvad vi tog til Geneve med, men der var stemning i lokalet for at lave det om, så adskillelsen blev mere markant. Derfor er conformance som udgangspunkt defineret i forhold til to schemas, "strict" og "transitional". "strict" indeholder ikke de "forældede ting" som VML og de to håndfulde compat-settings. Fra dokumentet "US-multi-part"_proposal_final.doc" kan man i øvrigt læse:

[b]DIS 29500 will be restructured to consist of the following parts:[/b]

[b]DIS 29500-1:[/b] contains the existing Part 1 (Fundamentals), Part 4 (Markup Language Reference) (...)
[b]DIS 29500-2:[/b] contains the existing Part 2 (Open Packaging Convention)
[b]DIS 29500-3:[/b] contains the existing Part 5 (Markup Compatibility and Extensibility)

[b]DIS 29500-4:[/b] contains the existing Part 3 (Primer), and the Accessibility guidelines requested by the disposition for comments CA-69, CA-72, and CA-73.

[b]DIS 29500-5:[/b] contains the transitional features [such as VML, collectively referenced as Selected Transitional Migration Features] within the existing Part 1 and Part 4, from the proposed annex created by the disposition for comment JP-0030.

Jeg mener dog at kunne huske, at Part 3 og accessibility-guidelines blev puttet ind i den nye Part 1, så der blev i alt i dele af OOXML i alt.

Henrik Jensen

Du ser desværre lidt for sort og hvidt på det efter min mening.

Som jeg skrev i mit tidligere indlæg så kig på den nuværende situationer med ODF standarden og de forskellige implementationer heraf. Hvordan ser billedet ud om 5-10 år? Jeg tror kun der er 3 muligheder

1) ODF-standarden indeholder elementer som kun eksisterer for at sikre bagudkompatibilitet med tidligere versioner af af OpenOffice, KOffice, yyy, xxx etc.

2) ODF-standarden indeholder ikke disse bagudkompatbilitets elementer, men tilgengæld så har de forskellige produkter extensions (superset) af standarden som gør det svært at sikre interoperabilitet

3) Nogle brugere og deres dokumenter kan være blevet ofret med hensyn til deres mulighed for fremadrettet at sikre 100% præsentations nøjagtig for deres dokumenter.

Mulighed 3 er nok den bedste set ud fra et standardiseringsynspunkt men denne beslutning bliver altså også svære og svære at tage efterhånden som der bliver flere brugere og sker det for ofte for en given applikation, så kan den risikere helt at miste sin tilslutning.

Så det ville da være rart at leve i en verden hvor man ikke behøver at kigge sig over skulderen men udelukkende kan kigge fremad, men vi må også se på hvordan vi bedst håndterer at sådan er verden nu engang ikke skruet sammen.

Anders Olsen

Mon ikke det vil foregå på samme måde som med alle andre standardiseringer. F.eks. browserne, hvor der nu er gået sport i at have de mest compliant implementationer, og vi efterhånden har fået elimineret det meste vendor-specifikke snask.

For mig at se, er netop MS' insisteren på at have al den bagud-kompabilitet med i en ISO standard blot en klods om benet på den process der skulle lede os i retning af den udvikling der er på browsermarkedet.

Og som en kommentar til din "Det er livsfarligt, hvis man kan se forskel"
Helt ærligt. Den er da tynd. Hvis man arbejder med data-konvertering, hvor der er liv eller formuer på spil, så implementerer man da kvalitetskontrol omkring det. Og hvis det viser sig at der ryger et linieskift i headeren på sin fut-togs dokumentation, så fixer man det specifikke problem når det opstår. Tro mig. I know, for jeg har konverteret tilnærmelsesvis endeløse mængder af dokumenter med financielle data fra forskellige mainframe systemer til nyere systemer.

Henrik Jensen

Man kan desværre ikke sammenligne de 2 markeder helt (browsere + office applikationer). Forskellen er at office applikationer dem benytter du til at producere noget (dokumenter) som peristeres i et format efter en standard, browsere benytter du blot til at vise noget som andre har produceret.

Hvis du producerede et dokument i år 2000 som du af en eller anden årsag (f.eks. juridisk) er nødt til sikre kan repræsenteres med 100% nøjagtighed så kan det være et problem at de office applikationer der findes i år 2008 ikke understøtte dette fordi de skal overholde en eller anden standard. Hvis du har produceret en hjemmeside i år 2000 som ikke længere kan repræsenteres med 100% nøjagtighed i de browser der findes i år 2008 så tilretter du bare hjemmesiden. Det er i hvert fald sjældent man har hjemmesider der har samme behov som dokumenter på det område.

Med hensyn til "ikke 100% nøjagtighed = farligt", så husk også at jeg sagde det med et stort grin på læberne og at det var et citat jeg huggede fra den ekspertgruppe der i EU kiggede på dokumentformater, herunder OpenOffice.org XML (ODF) og OOXML m.fl. Jeg ville selv grinende havde rystet på hovedet hvis nogle brugte dette argument den anden vej for at argumentere for at det var farligt hvis der ikke kun var 1 standard, så jeg medbragte det kun fordi jeg synes det var meget sjovt et ekspertgruppen benyttede det i sin tid (igen årsagen var det sjove, bestemt ikke det tragiske der skete!).

Jarnis Bertelsen

Jeg synes argumentet om persistens og 100% garanteret reproduktion er ret tåbeligt. Hvis du har et dokument der ikke må ændre sig det mindste er ethvert office format et forkert valg - det er det pdf er beregnet til.

Office dokumenter er i deres natur beregnede til at blive redigeret. Derfor vil der altid være mulige fejlkilder. Selv hvis programmet kunne garanteres til at vise dokumentet 100% ens, er der de menskelige fejlkilder, f.eks. at brugeren får ramt en tast uden at opdage det. En manglende eller ændret font kan også lave små forskelle med mindre de er inkluderet i dokumentet - som i pdf.

Hvis man har en række dokumenter i f.eks. Office95 format med ekstremt strenge krav om presistens så få dog Office95 til at udskrive dem til pdf. Det må endda kunne scriptes rimeligt nemt.

Eskild Nielsen

I en grufuld overgangsfase for mange år siden skulle jeg arbejde i ovennævnte programmer i flæng.

Mange ting forekom umiddelbart lettere i WW6 end i WP5.1, men NÅR der ind i mellem skete noget mystisk med dit WW6-layout, så var det så godt som umuligt at finde årsagen.

WP5.1 var muligvis tungere at arbejde med, men skete der noget uventet, kunne du blot vælge 'vis koder'. Her kunne du bådew se hvad der var sket, samt rense ud i vildskuddene.

Og det behøvede ikke at være WW6/WP5.1 kløften, der kunne skaffe besværet - du skulle bare samarbejde med nogen der brugte en anden dokumentskabelon end din, eller en anden WW6 version eller en anden Windows version. (Version omfatter også locale i denne sammenhæng).

Er der nogen der kender et importfilter for wp5.1 til OOo?

/esni

Henrik Jensen

Det er bare svært at stille alle tilfredse. Jeg ser mulighederne er følgende

1) Microsoft kunne havde pillet alle deres kompatibilitets settings ud af OOXML og placeret dem i et superset lige før standarden blev sendt til ECMA. Der var helt sikkert mange der også havde kritiseret dette og set det som et forsøg på vendor lock-in.

2) Så kunne Microsoft havde sendt en OOXML-1 og OOXML-2 med og uden kompatibilitets setttings ind, men det kan vi vel godt blive enige om heller ikke er helt optimalt.

3) Vi kunne få en OOXML standard hvor kompatibilitets settings ikke er obligatoriske.

Mulighed 3 ser altså bare ud som bedste alternativ.

Så kunne man selvfølgelig som nævnt i tidligere indlæg debattere om kompatibilitets settings skulle helt ud af OOXML og Office. Men hvad hvis der uanset at det er tåbeligt (brugeres veje er nogle gange uransagelige) stadig er nogle brugere der ønsker at kunne videreføre med 100% præsentations nøjagtighed i Office? Så er vi altså enige om at vi skal fratage dem denne mulighed, så kan vi begynde at kigge på de problemstillinger jeg tidligere har nævnt med at afgøre hvad der skal ud og hvad der skal blive.

Jeg har stadig ikke set nogen komme op med et konstruktivt og fyldestgørende forslag til hvordan vi præcis afgør hvornår vi ofrer brugere af hensyn til standardiseringen.

Anders Olsen

Men altså. Du repræsenterer muligvis de brugere, for hvem %100 bevaring af layout er nødvendigt ved gemning i et nyt format. Og det er så vigtigt at dem der måtte have dette behov, har fået et par års taletid gennem ISO processen.

Alt sammen meget fint. Men hvorfor har vi aldrig hørt disse menneskers røster, hver gang der er kommet nye versioner af Microsoft Office? Jeg har ikke tal på hvor mange gange jeg har åbnet et dokument i word eller excel for at gemme det igen, og fået at vide at visse uspecificerede elementer ikke vil blive gemt.

Det synes aldrig at have været genstand for denne type kritik før, da folk "i gamle dage" åbenbart kunne finde ud af at re-etablere de tabte ændringer, undlade at gemme i det nye format, gemme det i PDF eller andet.

Så for at etablere denne mulighed (hvis det overhovedet viser sig at kunne lade sig gøre) for at tilfredsstille en (må formodes) lille gruppe mennesker, der i stilhed har håndteret "problemet" i årtier, er al denne virak og uhensigtmæssigheder altså nødvendig? Sorry, but I fail to see it.

Henrik Jensen

Jeg er også til dels enig men som jeg tidligere har gjort rede for så er det ikke nemt at afgøre hvad der skal pilles ud.

I bliver ved med at sige at noget skal pilles ud men vil ikke konstruktivt gå ind i en debat om hvordan man afgør det jvf. de problemstillinger jeg har nævnt i tidligere indlæg. Så kommer vi aldrig videre.

Og som jeg siger så handler det også nogen gange om at acceptere historiens uretfærdigheder. EU nedsatte en ekspertgruppe i 2004, hvor de så glemte at få dig med, og det er faktisk der jeg hentede citatet omkring juridiske dokumenter og også ulykken i frankring i 1988 vedrørende 100% præsentations nøjagtighed. Denne ekspertgruppe endte op med en anbefaling om at Microsoft skulle overlevere deres XML formater til en standardigseringsorganisation. Der blev ikke nævnt at de skulle pille en masse ting ud af deres XML formater og så overlevere dem. Nu siger jeg ikke at denne ekspertgruppe gik så langt ned i formaterne så de overhovedet kunne vurdere dette, men vi kan vel heller ikke udelukke at EU havde set ilde på at Microsoft kun overleverede dele af deres formater til standardisering, jeg har i hvert fald ikke set en udmelding fra EU der bekræfter dette.

Desuden er det så også vigtigt at huske at ud af de 300+ millioner af brugere der er af Office på verdensplan så regner jeg altså med at det er en ganske ganske lille del der overhovedet tilnærmelsesvis kan overskue hvad alt det her standardisering er for noget og har af betydning for dem i deres daglige arbejde.

Anders Olsen

Jeg er ikke en af dem der argumenterer for at pille noget ud. Jeg siger bare, at det for mig er et pseudo-problem, fordi der er et hav af folk der har løst det problem et endeløst antal gange gennem tiden på forskellig vis.
Det kan muligvis gøres smartere, men jeg synes ikke det har noget med dokument-formater eller ISO certificeringer at gøre. Det er en applikations-ting.

Jeg kan kun referere til mit tidligere indlæg omkring browsere. Jeg mener kun vi bør have 1 standard for dokument-udveksing med det offentlige, men jeg er personligt ligeglad med om det er ODF, OOXML eller noget helt andet. Jeg havde da ønsket at MS havde åbnet op og gjort åbne standarder på området relevant længe før EU domme og konkurrerende standarder tvang dem, but so it goes.

For mig er den lige til højrebenet. Det er op til alle interessenter at bringe erfaringer og learnings til bordet for at finde ud af hvordan standarden skal se ud. Har man lavet f.eks. datoer på en åndssvag måde i dokumenter i gamle dage, er her muligheden for at skrotte hvad der ikke var smart, og gøre det ordentligt. Det er ikke lykkedes Microsoft at samle interessenterne igennem årene, og nu kom der en anden standard. Så må de bide i den sure og sætte sig til bordet så vi alle kan komme videre.
Herfra er det så applikations-producenternes opgave at "innovere" omkring standarderne, ligesom man ser alle andre steder, browserne f.eks.

Anyways, sådan ser jeg det ihvertfald. ;-) Jeg ved udemærket det ikke er lige så simpelt i virkeligheden, men hvis vi ser bort fra MS og IBM's pubertære hanekampe, så er det vel nogenlunde dét, det handler om.

Anders Olsen

Hov, jeg overså et indlæg fra dig som osse skulle have en kommentar:
Jeg mener ikke der er noget problem overhovedet i at sammenligne standarder for browsere og officepakker. Det er begge applikationer til behandling af dokumenter indeholdende kode og data. Jeg producerer dagligt i min browser, ligefra når jeg skriver dette indlæg, til når jeg bruger vores backend systemer.

Og den med dit år 2000 dukument som skal gengives %100 holder altså ikke vand. Der er intet der forhindrer en officepakke i at åbne, bearbejde og lukke i alle de formater du har lyst til. Du kan så risikere at et ønske om at gemme i et nyt format vil fejle pga. standarden for formatet. But so what??? Skal de konverteres, så laver vi en konvertering som vi altid har gjort, med tilhørende kvalitetskontrol.
Hvis du har tænkt dig at konvertere en stak gamle doc-dokumenter til OOXML, og du har et krav om %100.000 fidelity af juridiske eller personfarlige årsager, så siger jeg stakkels dig, hvis du forlader dig på en producents implementering af OOXML (også selvom det er MS). Der skal konverteres. Ikke bare åbnes og gemmes.

Og juridiske dokumenter bør iøvrigt gemmes i persistente formater (pdf feks), hvis du ønsker at de ikke skal kunne manipuleres med vilje eller ved uheld.

Henrik Jensen

Det er begge applikationer til at behandle (vise) dokumenter men office applikationer er også til at oprette dokumenter, dvs. at applikationen er ansvarlig for at mappe mellem funktionalitet og format der gemmes i.

Fordi at du har oprettet et indlæg på version2.dk så betyder det jo ikke at den browser du har benyttet har været ansvarlig for den HTML + CSS der ligger på version2.dk's hjemmeside, den har kun været ansvarlig for at præsentere det.

Jeg har tidligere sag at man da godt kunne sige til brugere der ønsker disse gamme funktionaliteter at de bare kan blive ved med at benytte doc format, men der er jo delte holdninger og det er altså ikke let...

Hvis vi kigger på historien

1) Microsoft holder fast i lukkede doc formater i mange år og de bliver kritisereret for ikke at udarbejde åbne formater.

2) Microsoft udarbejder så XML formater og så bliver de kritiseret for at de ikke bliver vedligeholdt af en standardiseringsorganisation. EU kritiserer ikke men anbefaler at de gør det.

3) Microsoft overleverer til en standardiseringsorganisation og så bliver de kritiseret for at det ikke var hele Office formatet men kun dele af det "man" ønskede standardiseret

Kan du gætte hvad der sker hvis Microsoft tager alle bagudkompatibilitets settings ud igen og placerer dem i et superset? Korrekt så vil de blive kritiseret for at ISO standarden ikke passer overens med det som Office genererer og at de gør dette for at skabe vendor lock-in.

Men jeg glæder mig meget til når vi sidder om 8-10 år og kigger tilbage på historien for ODF og implementationer heraf. Hvad tror du der bliver valgt af løsning?

1) Bagudkompatibilitet bliver holdt i superset som mindsker muligheden for interoperabilitet mellem forskellige implementationer af ODF?

2) Bagudkompatibilitet bliver indlejret i ODF ligesom det er gjort i OOXML?

3) OpenOffice, KOffice m.v. benytter en praksis hvor de max. understøtter en bagudkompatibilitetsfunktion i måske 3 år og derefter så ofrer de bare brugerne uanset hvor få eller mange de måtte være, og brugerne må så bare blive hængende i gamle versioner af applikationerne?

Henrik Jensen

Og lige en ting jeg glemte. Hvis man ønsker at implementere sin office applikation så den ikke understøtter disse gamle kompatibilitets ting fra Office så gør man jo bare dette, ønsker man at understøtte så gør man det i stedet.(Strict / Transitional ligesom med HTML/XHTML)

Havde Microsoft fjernet dem fra OOXML og placeret dem i et eget superset så kunne man principielt ikke selv vælge.

Anders Olsen

Om bagudkompabilitet: Jeg mener det er en and. Jeg kan simpelthen ikke se scenariet. Har man dokumenter i "gamle" formater, konverterer man dem man skal bruge og arkiverer resten. Det er ikke et større problem idag end før, og vi har klaret det fint i årtier.

Om browsere/officepakker/andre applikationer. Jeg ser ingen forskel. Det samme gælder for mail. Alle mailprogrammer har forskellige featuresets men implementerer de samme mail-standarder. (Bortset fra når man får mails fra folk, der har enablet underlige "features" i exchange eller outlook ;-)

Om 8-10 år.. Svært at sige. Jeg tror der sker følgende. Microsoft Office producerer OOXML dokumenter som kun giver mening i Microsoft Office pga. proprietære funktioner, makroer, drm, integration med andre Microsoft programmer og platform osv.
Microsoft Office gør det GUI-mæssigt friktionsfuldt at anvende andre formater ved f.eks. ikke at kunne gemme preferencer for valg af anden standard format eller lignende.

Politikerne i Danmark siger at de nu "er åbne" og at der nu er konkurrence. Alle bliver frivilligt eller tvunget til Microsoft Office brugere, og status quo består.

Der går en række år, mens alle andre applikationer til over tid enes om et featureset af specifikationen som alle implementerer på samme måde.
Microsoft tilbyder til sidst en compatibility-mode som producerer samme type dokumenter uden proprietære elementer som alle andre. Dvs. noget ala. den samme udvikling som browsermarkedet med activex og lignende, blot går der 8-10 år før vi når derhen istedet for at starte der med det samme.

Noget i den stil. Microsoft har tjent en anseelig del af deres overskud på, at andre ikke kan implementere deres formater perfekt, og jeg ser ingen grund til hvorfor de skulle ændre på det, hvis de ikke blev tvunget til det ved enten en retssag, eller fordi det simpelthen bliver så stor en belastning for markedet at der bliver sagt fra, ligesom på browsermarkedet.

Henrik Jensen

Om det er en and det ved jeg ikke jeg har ikke selv overblikket over de 300+ millioner brugere og deres brug af office værktøjerne. Men faktum er at disse settings de nu engang findes i Office fordi at Microsoft ikke besidder din viden om brugerne, det må vi acceptere.

Så siger du to ting:

1) Der skal fjernes en del elementer fra OOXML standarden som findes i Office

2) I fremtiden vil Microsoft producerer OOXML dokumenter som benytter elementer der kun findes i Office og ikke i OOXML standarden.

Jamen punkt 2 det tvinger du jo dem jo til via punkt 1. Du slutter med at sige at Microsoft har tjent en anseelig del af deres overskud på at andre ikke kan implementere deres formater og du ser ingen grund til hvorfor det ikke skulle ændre sig.. nej og der er ikke engang en teoretisk chance for at det kan ændre sig hvis du tvinger dem til at hive elementer ud af OOXML standarden som findes i Office. Du vil hjælpe Microsoft til at kunne videreføre denne adfærd og samtidigt kritiserer du dem for det...

Du nævner browsermarkedet. Hvad synes du om at Microsoft har implementeret proprietære funktioner/superset af standarden i deres browser? Hvis du synes det er en dårlig idé hvorfor synes du så at inden for office applikationer der skal vi tvinge Microsoft ud i det samme fra dag 1?

Jeg synes ikke du svarer ordentligt vedrørende fremtiden angående ODF og forskellige ODF implementationer. Du siger at de vil blive enige om et featureset så det må betyde at superset af standarden ikke er en mulighed (ellers er de jo ikke blevet enige om et delvist featureset), så du har i hvert fald udelukket 1 af de 3 muligheder jeg nævnte, hvilket lader disse to tilbage

1) Bagudkompatibilitet bliver indlejret i ODF ligesom det er gjort i OOXML?

2) OpenOffice, KOffice m.v. benytter en praksis hvor de ikke garanterer bagudkompatibilitet i deres applikationer. Dvs. vi kan f.eks. ikke være sikre på at f.eks. OpenOffice 3.0 kan 100% præsentere ODF dokumenter produceret i OpenOffice 2.4 o.s.v. ?

Hvid du skulle vælge 1 af disse eller udelukke en af disse hvilken skulle det så være?

Anders Olsen

Jeg er ikke helt med på hvad du mener.

Jeg kan stadig ikke finde ud af at quote, men du skriver "[...]Du vil hjælpe Microsoft til at kunne videreføre denne adfærd og samtidigt kritiserer du dem for det..."

Bemærk venligst at jeg ikke kritiserer dem for noget i denne sammenhæng, og hvis jeg havde aktier i dem, ville jeg nok forvente at de gjorde hvad de kunne for at beskytte pengestrømmen inden for lovens grænser. Og hvis det inkluderer at gøre det problematisk for konkurrenter at "lege med" så gøres det vel formodentligt.

Du synes ikke jeg svarer ordentligt på fremtiden vedr. ODF. Det mener jeg at jeg gjorde, men så lyder uddybningen; For Danmark's vedkommende vil ODF dø som "nationalt" format ret hurtigt, da det nuværende forsøg med ODF/OOXML vil få politikerne til at konkludere at der er flest der bruger OOXML, og så sætter de sig på den.

Jeg har ikke set/hørt om nogen Officepakke (hverken OO eller MS eller andre), der garanterer bagud- eller fremad- kompabilitet overhovedet. Jeg er overbevist om, at hvis du skal konvertere informationer fra 1 format til et andet, og du har specielle krav som f.eks. 100% tro gengivelse skal du enten købe et professionelt konverterprogram eller gøre det selv.

Henrik Jensen

Den mulighed havde jeg ikke tænkt over nej... hvis ODF dør som format så slipper de selvfølgelig for at overveje deres strategi vedr. bagudkompatibilitet.

Men uanset om vi ender op med 1, 2 eller flere standarder så skal problematiken med bagudkompatibilitet håndteres af de standader der overlever. Konvertering er ikke svaret, udover at det da virkelig ville være skørt hvis vi også skulle til at havde convertere mellem OpenOffice 2.4 ODF og OpenOffice 3.0 ODF (Hvorfor så overhovedet havde en standard hvis ikke engang dette er muligt uden konvertering), så er problemet jo at man kan ikke konvertere til en funktionalitet (præsentationsform) som ikke længere eksisterer og det gør den jo nødvendigvia ikke fordi at vi ikke vil bibeholde bagudkompatibilitet.

Jeg kan selvfølgelig godt se at hvis alle brugere blot lærer at leve med at at man ikke skal forvente at dokumenter bliver præsenteret ens eller i det mindste meget tæt på ens med mindre man benytter akkurat samme applikation inkl. version som da dokumentet blev oprettet så er problemet jo praktisk løst. Men vi har bestemt også mistet en hel del af værdien ved overhovedet af standardisere.

Anders Olsen

Det jeg ærgrer mig over er, at Microsoft har blæst på bagud-kompabilitet ved format-skift mange gange. Nu er de på banen med endnu et nyt format som skal være en ISO standard, og så skal det gudhjælpemig lige pludselig være bagudkompatibelt med alle de gamle individuelt inkompatible formater.

Her mener jeg, at vi alle var bedre hjulpet, hvis vi startede med en ren tavle og tog de ting med, der var gode og droppede dem der var dårlige. Bemærk, det forhindrer jo ingen i at arbejde videre i de gamle formater overhovedet. Med mindre office-pakke producenten dropper support, hvilket de ikke gør hvis der er et marked. Med mindre man har et monopol man kan læne sig op ad ;-) Hvilket jeg ubestridt også ville gøre, hvis jeg kunne.

Jeg ved ikke hvorfor der skulle konverteres mellem OO2.4 og 3.0, med mindre de understøttede forskellige standarder. Og open source kendetegnes iøvrigt ved at support for ting er noget der akkumuleres og ikke noget der droppes.

Og du skriver at hvis ikke 100% gengivelse er muligt, mistes værdien ved standardisering. What????
Folk anvender idag ikke ODF som standard fordi det gengiver gamle MS dokumenter perfekt. Værdien opstår af helt andre årsager, og På Trods af at gengivelsen af f.eks. proprietære MS formater ikke er perfekt.

Henrik Jensen

Grunden til at man jo er nødt til at havde en strategi vedrørende bagudkompatibilitet er jo den at mennesker laver fejl.

Overordnet har vi 3 fejlkilder

1) Elementer i standarden kan være underspecificeret og kan derfor reelt implementere på to eller flere forskellige måder

2) Udviklere kan misfortolke standarden og derved implementere forkert

3) Udviklere kan implementere forkert selvom de har forstået standarden korrekt.

Hvis vi tager ODF som eksempel (problemet vil være det samme med OOXML) så kan vi altså risikere at der er lavet fejl (og når jeg siger fejl i denne sammnenhæng tænker jeg kun på fejl relateret til elementer i standarden) i OpenOffice 2.4, KOffice 1.6 og Lotus Notes 8 som gør at selv om de alle benytter ODF standarden så er interoperabiliteten ikke 100% imellem dem, og det er jo i et eller andet omfang den nutidige situation vi er i.

På et eller andet tidspunkt begynder man så at forsøge at rette op på dette. OpenOffice 3.0 retter så nogle fejl fra OpenOffice 2.4 så de kommer til at overholde ODF standarden eller i hvert fald kommer tættere på at overholde den. Der kan så vælges forskellige strategier

1) Bryde bagudkompatibiliteten (præsentationsmæssigt) så hvis du i 3.0 åbner dine ODF dokumenter oprettet i 2.4 så kan du risikere at de ser anderledes ud. OpenOffice skelner altså ikke men viser nu blot dokumenter oprettet i 2.4 og 3.0 fuldstændigt ens.

2) De kan tilbyde bagudkompatibilitet så dokumenter oprettet i 2.4 kan åbnes i 3.0 og ser ud som de oprindeligt gjorde i 2.4 eller i hvert fald så tæt på som de gjorde. Dette kan så gøres på et par forskellige måder

a) Man kan vælge at kunne åbne/gemme i to forskellige versioner (OpenOffice 2.4 ODF og OpenOffice 3.0 ODF)

b) Man kan vælge kun at åbne/gemme i én version og så havde nogle kompatibilitets settings som brugeren kan vælge fra eller til så 2.4 simuleres på denne måde

Ved løsning 1 så ofrer vi nogle brugere og ved løsning 2a så låser vi nogle brugere fast på at de skal leve videre med samtlige interoperabilitetsproblemer med KOffice, Lotus Notes o.s.v. uanset om det faktisk ikke er deres reele behov og med løsning 2b så introducerer vi de kompatibilitets settings som vi ikke ønsker hverken som superset eller dele af ODF standarden.

Det er ikke noget let valg og derfor skal man havde en strategi. Nu ved jeg godt at din strategi er at brugeren altid bare skal ofres, men det kan de altså også godt blive trætte af i længden, og spørgsmålet er også hvor meget man kan tillade sig at ofre brugerne.

Du nævner at 100% gengivelse ikke er nødvendigt. Men hvad er så grænsen? Vi kan vel blive enige om 25% er for lavt? Hvad med 50% hvad med 75%?

Jeg ved godt at procenttal er svært at sætte på så det kommer jo også helt an på element typen. Hvis f.eks. det er formler i regnearket det handler om kan vi så ikke i det mindre blive enige om at 100% nøjagtighed ikke ville være en dårlig idé og man skal prøve at opnå de 100%? Altså sådan så når du har opsat nogle store beregninger i OpenOffice 2.4 så ville det ikke gøre noget hvis dit resultat faktisk så 100% ens ud når du åbnede i OpenOffice 3.0 eller KOffice 1.6? Eller er det mig der stiller for store krav?

Min erfaring fra den civile retssag jeg er involveret i Indien i øjeblikekt er at retssystemet der, også på hvad der blot er almindelig tekst (selvfølgelig inklusiv forskellige typer af formatering), går meget op i nøjagtig. Jeg siger ikke at de forlanger 100% præsentations nøjagtighed men det er bestemt heller ikke langt fra.

Og der er flere eksempler hvor selv det der regnes
for små forskelle kan havde væsentligt betydning for forståelsen eller brugen. Jeg har prøvet lige at tænke lidt over et par eksempler:

1) Jeg nævnte formler i regneark tidligere, det er vist ret indlysende at selv lille forskel kan havde stor betydning.

2) Hvis der er selv de mindste forskelle i implementationen af afsnitsnummerering, listenummerering eller fields som f.eks. udskriver sidenummer så kan det jo havde stor betydning fordi at manuelle referencer (f.eks. fra andre dokumenter) jo så kan være forkerte.

3) Indrykninger kan også havde stor indflydelse på forståelsen. Nu kan man jo grine og sige at eksemplet med ulykken i 1988 er et tåbeligt eksempel, men faktum er jo at det var 2 forkerte indrykninger som gjorde at maintenance manualen blev forstået forkert.

4) Forskelle i wrapping af billeder kan i værste fald betyde at tekst bliver skjult bag et billede. Det kan også ændre væsentligt på forståelsen af dit dokument.

5) Der er brug af datoer som beregnes/formateres af applikationen selv lille unøjagtighed kan havde stor betydning for meningen, bare tag ombytning af måned + dag.

6) Selv simple tekst formateringsfejl kan give problemer med forståelsen hvis de er benyttet som referencer. F.eks. "Kun spørgsmål med fed skrift skal besvares", "Udfyld manglende felter markeret med understregning"

Der er sikkert væsentligt flere eksempler hvis man tænker sig om. Så i rigtig mange tilfælde vil jeg altså stadig påstå at hvis vi ikke opnår 100% nøjagtighed eller meget tæt på så mister vores standard værdi, da brugerne så alligevel ikke tør at åbne dokumenter i andet end den applikation inkl. version som det blev oprettet i.

Jeg siger ikke at Microsoft altid har sikret 100% nøjagtighed mellem versioner, men de lider jo af de samme problemer som alle andre nemlig at de har mennesker til at udvikle deres applikationer og mennesker begår fejl. Men betyder det at vi ikke skal forsøge at komme meget tæt på de 100% men bare være ligeglade fordi at vi måske netop kun kan komme meget tæt på og ikke helt op på 100%?

Anders Olsen

Jeg forstår ikke du påstår jeg mener at brugerne skal ofres. Tværtimod.

Min påstand er, at de applikationer, der måtte forsøge at følge en standard næppe vil være 100% konforme ved standarder af disse størrelser. Se bare på browserne. Når Microsoft (eller andre, for den sags skyld) kommer med et produkt som implementerer OOXML 100% perfekt og bliver ved med det i kommende versioner, skal jeg nok ændre holdning, men indtil da er det modsatte en realitet.

Det bør man som bruger acceptere og lære at leve med. Med mindre man allerede har lært det af de sidste årtiers historie.

Har du special-behov (som f.eks. 100.0000% gengivelse) bør du bruge pengene på et noget der kan sikre dig det. Det er jo fuldstændigt gak, hvis du i 1998 skrev og gemte et dokument i Word97, og du allerede da vidste at du havde et krav om at det skulle kunne åbnes, læses og gemmes fejlfrit af et helt andet program 15 år efter, hvis liv, lemmer og formuer afhang deraf.

Din sidste paragraf om 100% nøjagtighed understreger sådan set bare hvad jeg siger.

Henrik Jensen

Så er vi enige om at 100% næppe kan opnåes da mennesker begår fejl, men er vi også enige om at

1) Der er flere gode argumenter for at prøve at komme så tæt på 100% som muligt end der er for ikke at forsøge overhovedet, men bare altid sige at det må brugerne sgu selv rode med?

2) Hvis vi er enige om 1 så er vi vil også enige om at ODF får ekstremt svært ved at undgå at håndtere bagudkompatibiligt (ellers forsøger de jo ikke at opnå 100%). Det kan de enten gøre ligesom i OOXML eller via supersets af standarden. Så vi er altså ude i realistisk at må acceptere at ODF bliver nødt til at vælge 1 af 2 onder.

3) Hvis vi er enige om 1 og 2 så er vi vel også enige om at OOXML skal også forsøge at opnå 100% det er ikke kun ODF som skal forsøge dette. OOXML har så de samme 2 onder at vælge imellem hvad angår bagudkompatibilitet. Forskellen er vel så bare at OOXML (Microsoft) dem kritiserer vi uanset hvilke onde de vælger og med ODF der accepterer vi det uanset hvilket onde de vælger. Der er jeg så personligt bare mere af den holdning at jeg accepterer det begge steder fordi at jeg ikke fagligt kan argumentere for kun at gøre det ét sted.

Selvom det er et svært valg, så hvis jeg personligt skulle vælge mellem de 2 onder så ville jeg gøre det ligesom det er gjort i OOXML med den begrundelse af det tilgodeser flest muligt.

  • Hvis vi kigger på ODF så håndterer de indtil videre bagudkompatibilitet i supersets (extensions). Det betyder at hvis du benytter nogle af disse elementer fra supersettet i OpenOffice så har du allerede teoretisk fraskåret dig fra at opnå 100% interoperabilitet (hvis vi ikke ser reverse engineering som brugbart på sigt) med KOffice, Lotus Notes o.s.v., hvis du benytter elementer fra supersettet i KOffice har du allerede teoretisk fraskåret dig fra at opnå 100% interoperabilitet med OpenOffice, Lotus Notes o.s.v.

  • Hvis vi kigger på OOXML så hvis du kun implementerer OOXML Strict (altså uden disse bagudkompatibilitets settings m.v.) så har du allerede fraskået dig fra at opnå 100% interoperabilitet med de applikationer der også understøtter OOXML Transitional. Men du definerer i det mindste din manglende interoperabilitet mellem to forskellige skemaer som begge vedligeholdes i en standardiseringsorganisation (OOXML Strict + OOXML Transitional), hvorimod du i ODF definerer din manglende interoperabilitet mellem et skema der vedligeholdes i en standardiseringsorganisation (ODF) og så flere skemaer som vedligeholdes af de enkelte applikationer, OpenOffice, KOffice, Lotus Notes o.s.v.

  • Hvis vi igen kigger på OOXML så kan du også vælge udover OOXML Strict at understøtte OOXML Transitional (altså inkl. bagudkompatibilitets settings m.v.) og så bibeholder du en teoretisk chance for at opnå 100% interoperabilitet med andre applikationer der også understøtter OOXML Transitional, herunder Microsoft Office.

Log ind eller Opret konto for at kommentere