Ekspertudvalg: For tidligt at bedømme ODF og OOXML

tror da faen, det er da lidt svært at bedømme et format (OOXML), der kun eksisterer (delvist) på papir, eftersom dem der har skrevet det ikke kan finde ud af at implementere det?
ODF, derimod er det da pjat at de ikke kan bedømme, det har været implementeret i årevis?
Hvis de mangler erfaring, må det jo være fordi de ikke følger deres egne retningslinier om format-åbenhed?
<sarkasme> Jeg er chokeret! chokeret siger jeg!</sarkasme>

"Danmark er nu med i front"

blah blah blah... man slår en skid i modvind, og straks er alt i verdensklasse!!

Rapporten: "Vi ved ikke noget."

Politikerne: "Med udfærdigelsen af denne rapport er vi nu med i fronten!"

Mig: "wtf?"

Hvis det er den standard vi sætter os, så vil jeg da med glæde modtage et par millioner for at udfærdige en rapport der forklare hvorfor vi ikke aner noget om fusion i danmark, så vi også kan komme med i fronten på det felt.

vi kan ikke tage nogen beslutninger, men vi er med i front mht. til at overveje hvad vi skal gøre deeeeet er skam godt nok. FFS!! Så tag dog en beslutning og kom videre

En politiker tage en beslutning?

0 skrev:

Rapporten understøtter dermed ministeriets beslutning om, ikke at lægge sig fast på kun et bestemt format.

Hvorfor også lægge sig fast på ét bestemt af de to formater?

Hvor svært kan det være at håndtere begge to?

#6 man kan godt prøve at håndtere begge formater, men der er ligesom kun eet der kan være "standard".

Må, efter at have læst rapporten, give dem ret i problemstillingen med at ligge sig fast på et format på nuværende tidspunkt.

Det ville klæde diskutionen hvis folk bare ville læse de relevante link i en artikkel (da de mange gange har en stor indvirkning på forståelsen af nyheden) inden man skrev sine kommentarer.

Lad os lige slå fast, at det kun er version af ODF 1.0 der er blevet ISO godkendt og den udgave af OOXML der har fået stemplet, er af en nyere udgave end den der er implememteret i Office på nuværende.

Problemet her er jo, at selvom ODF har været implementeret i årevis, så er implementeringen ikke ens i alle programmer.

Rapporten beskriver 16 forskellige programmer til MAC, Linux og Windows og nogle kan læse det ene format, nogle kan læse/skrive til et format, nogle kan læse et format, men læse/skrive til det andet format etc...
Man kan altså blive nød til at konverterer mellem de to formater og der er altså version 1.0, 1.1 og 1.2 at tage hensyn til.

Problemerne kan også være, hvordan implementeringen viser det færdige dokument.

Når du henter et dokument fra staten, gemt i f.eks ODF format,, så skal din maskine gerne vise dokumentet på præsic samme måde, som skribenten har gemt det.

Rapporten giver eksemplet med fonte som et problem. Hvis et dokument er skrevet ved hjælp af en font, gemt i ODF, og du så åbner det på en maskine, der ikke har den font installeret. Hvad så?

Har du fonten, er det ikke engang sikkert at det hjælper, da renderingen af en given font, kan være forskellig fra OS til OS.

Betanews har haft problemstillingen oppe og vende i forbindelse med Microsoft initiativ til, at beskrive hvordan de har tænkt sig, at implementere ODF 1.1 i Office 2007 SP2.

Her kommer de med flere eksempler på problemstillingen. F.eks problemet med forskellen på implementeringen i programmer som alle har forskellige funktioner.
Hvordan gemmer man en funktion i et ODF dokument, hvis funktionen ikke er beskrevet i ODF formatet?

Man kan, visual, se eksemplerne beskrevet på Doug Mahugh's blog, om emnet.

Bare fordi et dokument format er blevet godkendt, så er det ikke noget man bare implementere og så er verden lysegrøn.

#7: Ja den er jeg med på. Jeg tænkte bare at de kun ville acceptere ét af formaterne. Det ville da være skidt hvis det blev sådan IMO.

#8: Interessant kommentar!

runeks (6) skrev:

Hvor svært kan det være at håndtere begge to?

Tjah, umiddelbart skulle man vel tro at det er omkring dobbelt så besværligt at håndtere to, som at håndtere ét.

Det skaber desuden et potentielt problem, som jeg tror vi også vil se i praksis:
Hvis både ODF og OOXML kan bruges, vil rigtigt mange nok bruge OOXML, og glemme at ODF skal understøttes. Og så har vi pludselig kun ét format i praksis alligevel.

runeks (6) skrev:

Hvor svært kan det være at håndtere begge to?

Tja.

1 format => konverterings udgifter = 0

2 formater => konverterings udgifter = xxx millioner om året

Jeg kan se en forskel.

starz#1 (1) skrev:

ODF, derimod er det da pjat at de ikke kan bedømme, det har været implementeret i årevis?

Prøv at læs rapporten.

(eller #8)

myplacedk (10) skrev:

Tjah, umiddelbart skulle man vel tro at det er omkring dobbelt så besværligt at håndtere to, som at håndtere ét.

Jeg vil mene at problemerne er proportionale med n>1 ? n*(n-1)/2 : 0 ikke proportionale med n.

myplacedk (10) skrev:

Det skaber desuden et potentielt problem, som jeg tror vi også vil se i praksis:
Hvis både ODF og OOXML kan bruges, vil rigtigt mange nok bruge OOXML, og glemme at ODF skal understøttes. Og så har vi pludselig kun ét format i praksis alligevel.

Det er et meget realistisk scenarie.

#13

Hm.

n>1 ? n*(n-1)/2 : 0

kan vist godt kortes ned til:

n*(n-1)/2

Her er en sammenligning af ODF og OOXML. Den er ikke daekkende, men mon ikke nedenstaaende blot er toppen af isbjerget.

http://www.theopensourcerer.com/2008/03/18/ooxml-i...

#15
...ligesom en slipsenål ikke er dækkende, når man kommer ud fra badet og opdager at man har fået gæster.

Men det er en indikator, og der er noget om det. Det er et fint eksempel på OOXML's mærkværdigheder.