Jesper Lund Stocholm bloghoved

Konklusionspapiret om dokumentformater

I de sidste 5 minutter af 11. time blev der i fredags forhandlet en aftale på dokumentformatområdet. Alt andet lige er jeg glad for, at der blev indgået (i det mindste) én eller anden aftale i stedet for igen at udskyde enhver beslutning.

Men desværre gik det jo åbenbart hedt for sig derinde på Borgen - i hvert fald rapporteredes det jo her på version2, at der var ændret i konklusionspapiret indtil 5 minutter i 10.

Lad mig sige det med samme - jeg kender alt til, hvad det betyder at arbejde under stress og pressede tidsfrister ... og hvad det kan betyde for kvaliteten af det arbejde, det kan resultere i (BRM, anyone?).

Derfor synes jeg, at det kunne være på plads at lave* min* version af aftalen - hvis jeg skulle have skrevet den.

Men lad mig først komme med nogle generelle betragtninger omkring dokumentet og dets indhold. Dokumentet er jo "afløser" for beslutningen fra 2007, hvor der blev defineret to tilladte formater og dertil lavet en aftale med kommuner og regioner omkring udmøntningen af aftalen.

Papiret fra i fredags er et kæmpe skridt i den rigtige retning. I stedet for at vælge en liste af dokumentformater, har politikerne defineret krav for at komme på listen. Dermed har man gjort det man som politiker gør bedst - nemlig at udstikke politiske/strategiske krav og ønsker - og derefter outsourcet "implementeringen" til fagfolk - i dette filfælde regeringens "ekspertudvalg". Dertil har man - ikke mindst! - vendt det oprindelige "modtagekrav" til et "sendekrav". Der er nu krav om, at også afsendelse af kommunikation fra det offentlige skal ske via de åbne dokumentformater. Dermed kan vi ikke komme i den situation, at en myndighed forpligtes til at modtage åbne dokumentformater og selv afsender i DOC-formatet.

Som den opmærksomme læser vil bemærke, har jeg fjernet nævnelsen af ODF fra dokumentet. Det har jeg gjort ud fra den betragtning, at listen for det første jo ikke er lavet endnu. Derfor virker det mærkeligt, at man fra Folketingets side giver ekspertudvalget og OIO-komiteen ansvar for dannelse af listen - men samtidig blander sig i et enkelt formats apriori-placering på listen. For det andet antager jeg da, at alle dokumentformater - også ODF - skal opfylde kravene på listen for at komme på den - uanset at ODFs placering på listen virker oplagt.

Endelig har jeg vendt kravet om at "det skal demonstreres, at ..." til "det må ikke kunne demonstreres, at ...". Årsagen er det pragmatiske, at det er super svært bevise at noget altid kan lade sig gøre. Det er langt nemmere at vise at noget ikke altid kan lade sig gøre. En eller anden klog mand udtalte engang, at "der skal 1000 forsøg til at retfærdiggøre en teori - men kun et enkelt til at ødelægge den". Vi er jo efterhånden vante til FUD-spredning fra OSL og andre, der forsøger at skabe en stemning af usikkerhed omkring OOXML. Med min ændrede formulering tvinges de til at være konkrete omkring eventuelle proprietære bindinger eller at stikke piben ind.

Hvad siger I?

![Eksternt billede](http://www.version2.dk/uploads/smil3dbd4d6422f04.gif" alt=")

Konklusionspapir om anvendelsen af åbne standarder for software i det offentlige.

V, S, DF, SF, K, RV, EL har med tilslutning fra LA konkluderet
følgende vedrørende anvendelsen af åbne standarder i det offentlige:

  1. I medfør af folketingsbeslutning B103 (samling 2005/06) skal regeringen sikre, at det offentliges brug af informationsteknologi, herunder brug af software, er baseret på åbne standarder. Kravet om brug af åbne standarder gælder ved nyindkøb og ved større opdateringer og skal være udgiftsneutralt efter de gældende kriterier for den offentlige sektor.
.delete   
{  
    text-decoration:line-through;  
    color: #f00;  
}  
.add  
{  
    text-decoration: underline;  
    color:#00f;  
}

Nye krav til åbne obligatoriske standarder for dokumentformater

For at fremme anvendelsen af software baseret på åbne standarder i
det offentlige og for særligt at fremme
konkurrencen på kontorsoftware samt for at sikre, at borgere og
virksomheder ikke er afhængige af bestemte kontorpakker i deres
kommunikation med det offentlige, gøres følgende:

  1. Der oprettes en liste over godkendte obligatoriske åbne standarder i det offentlige med det mål, at fremme at offentlige myndigheder skal kommunikere ved hjælp af åbne standarder. Ekspertudvalget om åbne standarder, nedsat i efteråret 2008, vil efter inddragelse af den fællesoffentlige OIO-komite, indstille til videnskabsministeren, hvornår - og med hvilke standarder - listen opdateres. Følgende principper skal være opfyldt for, at en standard kan omfattes af listen. Standarden skal være:
  • Fuldstændigt dokumenteret og offentligt tilgængelig.
  • Frit implementerbar uden økonomiske, politiske eller juridiske begrænsninger på implementering og anvendelse.
  • Godkendt af en international anerkendt standardiseringsorganisation, eksempelvis ISO, og standardiseret og vedligeholdt i et åbent forum via en åben proces.
  • Det skal demonstreres, at standarden kan implementeres af alle direkte i sin helhed på flere platforme.
  • Der må ikke kunne demonstreres tekniske eller specifikationsmæssige hindringer for, at enhver leverandør kan implementere standarden i sin helhed på en af denne valgt platform.
  • Interoperabel inden for funktionalitetsloftet med andre standarder på listen.

Ikke-redigerbare dokumenter

  1. Alle offentlige myndigheder vil med virkning fra 1. januar 2010 være forpligtede til at afsende dokumenter til borgere og virksomheder, der ikke skal indgå i en redigerbar proces skal læses, men ikke redigeres, i PDF/A-1 (ISO/IEC 19005-1:2005). Det samme gælder, når myndigheder publicerer dokumenter, der skal læses og ikke redigeres, på myndighedernes hjemmesider.

Redigerbare dokumenter

  1. Statslige myndigheder (1) vil fra 1. april 2011 være forpligtede til at afsende og kunne modtage dokumenter i formater omfattet af listen som er nævnt under punkt 2 - herunder ODF. For at sikre at alle, uanset platform, har adgang til redigerbare dokumenter, skal statslige myndigheder, såfremt de publicerer redigerbare dokumenter på deres hjemmesider, gøre dette i ODF og andre dokumentformater, som er optaget på listen. Dokumenter offentliggjort på hjemmesider, der ikke skal indgå i en redigerbar proces, skal offentliggøres i PDF/A-1 (ISO/IEC 19005-1:2005).
  2. Regeringen optager forhandlinger med kommuner og regioner med henblik på snarest at implementere de statslige åbne standarder efter følg eller forklar princippet.

Øvrige formater

  1. Herudover skal alle offentlige myndigheder fortsat – for at sikre borgerne maksimal valgfrihed – også kunne modtage dokumenter i alle gængse formater med stor udbredelse inden for anvendelsesområdet (2)
  2. Partierne noterer sig, at man løbende vil følge udviklingen af standard for dokumentformater på baggrund af den årlige It- og telepolitisk redegørelse.
  3. Indtil listen træder i kraft, må der ikke opstå tekniske hindringer gennem nyindkøb og større opdateringer af kontorsoftware i staten, der kan hæmme indførelsen af åbne standarder. Fremtidigt kontorsoftware skal som grundelement have den/de fastlagt åbne standarder fra listen omtalt i punkt 2.
  4. Partierne er enige om, at staten i sin fremadrettede indkøbspolitik for software skal fremme konkurrencen ved bl.a. at tage hensyn til den bekymring Konkurrencestyrelsen rejser i sin rapport (3)

(1) Myndigheder forstås her som departementer og styrelser mv.

(2) Ved "gængse formater med stor udbredelse inden for et
anvendelsesområde" forstås formater, som myndighederne jævnligt støder
på inden for et givet område.

(3) Punkt 5.2 i rapporten: "Juridiske bindinger knyttet til kontorsoftware", 11. juni 2009, Devoteam for Konkurrencestyrelsen

Kommentarer (101)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Carsten Pedersen

Endelig har jeg vendt kravet om at "det skal demonstreres, at ..." til "det må ikke kunne demonstreres, at ...". Årsagen er det pragmatiske, at det er super svært bevise at noget altid kan lade sig gøre.

Der er altså en betydelig forskel mellem at "demonstrere" og "bevise".

Men ellers er det da et smart retorisk trick du kommer med her: At man kan få godkendt en standard uden at skulle røre en finger, og når andre senere kommer forbi og siger at noget ikke kan lade sig gøre, så er løbet kørt.

Vi kan også fremover vedtage, at nye typer biler automatisk godkendes til at køre på motorvejene indtil det øjeblik nogen beviser de ikke er egnede til det. Hvorfor stille krav til producenten om at de skal sandsynliggøre at bilerne er sikre? Det er jo umuligt at bevise!

  • 0
  • 0
#5 Eskild Nielsen

Der må ikke kunne demonstreres tekniske eller specifikationsmæssige hindringer for, at enhver leverandør kan implementere standarden i sin helhed på en af denne valgt platform.

Dette svarer til at kræve et bevis for at en ny teknologi ikke har skadevirkninger. Lyder godt men byrden kan reelt ikke løftes.

Den oprindelioge formulering er bedre, fordi den 'blot' kræver at man porterer samme applikation til de relevante platforme.

Med den læsning af aftalen i FT's formulering, så bliver den byrde MS skal løfte at de releaser MS-Office som betalingssoftware til Linux med minimum den funktionalitet som ders Mac udgave har - og den skal vel at mærke reelt være til at købe - ikke kun vapourware

/esni

  • 0
  • 0
#7 Jesper Lund Stocholm Blogger

Hej Carsten,

Vi kan også fremover vedtage, at nye typer biler automatisk godkendes til at køre på motorvejene indtil det øjeblik nogen beviser de ikke er egnede til det.

Ja, eller hvad med at sammenligne "to standarder" med "to sporbredder for jernbaner"?

:o)

  • 0
  • 0
#9 Jesper Lund Stocholm Blogger

Hej Poul-Henning,

Er dette blogindlæg indikativt af den arbejdskvalitet du bringer til bordet i standardsammenhæng ?

Jeg var egentlig blevet lidt småmobset over dit indlæg, men så kom jeg i tanker om, at du jo har en lang og gloværdig historik for at komme med kontante udmeldinger baseret på sporadisk/kursorisk kendskab til emnet.

... så læs du blot mit indlæg en 3-4 gange endnu ... du skal nok forstå det til sidst.

:o)

  • 0
  • 0
#10 Jesper Lund Stocholm Blogger

Hej Eskild,

Den oprindelioge formulering er bedre, fordi den 'blot' kræver at man porterer samme applikation til de relevante platforme.

Nej - for der står

"kan implementeres af alle direkte i sin helhed på flere platforme."

Det er dermed ikke nok, at én leverandør (som jo tilfældigvis kunne være opdragsgiver for dokumentformatet) implementerer formatet på flere platforme. Det skal derimod demonstreres, at ALLE kan implementere formatet I SIN HELHED på flere platforme.

Hvordan vil du gøre det?

Dette er netop pointen med min omskrivning - det oprindelige krav giver ikke mening i den virkelige verden.

At Suns implementering af ODF er tilgængelig på et hav af platforme opfylder IKKE, at ALLE kan implementere den i SIN HELHED på flere platforme. Det viser kun, at Sun kan.

Tilsvarende - selvom Microsoft porterede Office til alle platforme, så ville det kun vise, at Microsoft kunne implementere OOXML - ikke at alle kunne.

Jeg gentager det gerne - det oprindelige krav giver ikke mening - og derfor min omformulering.

:o)

  • 0
  • 0
#11 Eskild Nielsen

Hej Jesper

Jeg medgiver, at det også er problematisk at tale om 'af alle' da det ikke er muligt at udtale sig om motiverne for at fravælge en eller flere platforme at implementere på.

Det ideale krav er at alle interesserede kan implementere, og at der på alle platforme er nogen,de har implementeret med tilstækkelig funktionalitet.

Det tætteste man så i praksis kan komme dem første del er den gamle IETF tese om 2 uafhængige implementationer, og der kommer der også hurtigt problemer når der er store summer på spil.

Men det ændrer ikke meget ved at der

  • 0
  • 0
#12 Poul-Henning Kamp Blogger

Jeg var egentlig blevet lidt småmobset over dit indlæg,[...]

Det er jeg da ked af at høre, for spørgsmålet var helt seriøst ment.

Hvis du skal igennem flere tusinde siders OOXML specifikation med den opmærksomhed på solstolenes opstilling på dækket af Titanic, har du tydeligvis fundet det job du skal pensioneres fra...

Poul-Henning

PS: Jeg er selvfølgelig godt klar over at du er ved at lægge bunden til noget astroturf-lobbyisme, der skal ende i at Folketinget laver et smuthul til OOXML, så du behøver ikke svare hvis det hidser dig op eller ødelægger dit gode humør.

  • 0
  • 0
#13 Ayhan Binici

Hej Jesper,

Jeg vil give PHK ret. Ofte når man læser dine blog-indlæg fornemmer man en eller anden skjult intention, der som regel er at advokere for djævlen. Dette indlæg er ingen undtagelse. Det lugter langt væk.

Du behøver ikke at gøre dig den ulejlighed at omformulere det ene og det andet. Der er ikke plads til OOXML på den famøse liste. Alle disse anstrengelser fra vores og oppositionens side er netop for at bryde den onde cirkel. OOXML er en del af denne onde cirkel.

Desuden hjælper det ikke på dit anstrengte ry som neutral når du angriber OSL og os andre for at sprede FUD. Fej lige for egen dør først, mister MVP.

  • 0
  • 0
#14 Christian Høier

Hej Jesper

Hvorfor bliver du sur over Poul-Henning's kommentar?

Er det fordi du også kan se at denne form for spind er lidt usmagligt.

Først sætter du tvivl ved folketingets evner, så omskriver du et officelt dokumentet og tilsidst prøver du at pakke det ind i fagligt tåge snak.

Det er i mine øjne en lille smule respektløs over for alle som har deltaget i processen.

  • 0
  • 0
#16 Carsten Olsen

Jeg tror at fremtiden vil vise at html blev de facto standard.

mht. in-lejret code som formel felter kan det laves i JAVA .

Faktisk kan hele aplicationen være java f.eks. "/code/word.html" på webserveren

google prøver at adressere nogen af problemerne i dette med:

V8 (java engine) (hastighed) Google Web Toolkit (Open Source værktøj) Chrome OS (indeholder browser der kan kører multi trådet (hastighed) (god bruger oplevelse) browseren kører også applicationerne 100% adskilt (sikkerhed) Chrome OS har problemer med printere. (kan løses ved at lade printerne kører html5)

Kort sagt livet er for kort til virus inficeret "proprietær kode" med "lock-in"

  • 0
  • 0
#17 Jesper Louis Andersen

Og hvor er det dog rart at se fornuften sejre. OOXML er teknisk set en for stor standard til at den er smart at satse på. I princippet er ODF også for stor, men i det mindste er vi nu noget tættere på målet end tidligere.

Bemærk også at det sætter funktionalitetsloftet forholdsvist lavt. Havde vi valgt OOXML (der formentlig har et højere funktionalitetsloft og helt givetvis har større teknisk kompleksitet), så havde vi risikeret at vi kun ville benytte 20% af standarden i praksis. Det er spild af tid, giver samarbejdsproblemer systemerne imellem etc.

Det er nemt nok at gøre en standard mere kompleks ved at tilføje til den. Det er meget sværere (og langt mere innovativt) at finde de uafhængige dele som er minimale og udgør en løsning. Det giver også mulighed for at lave standarden som en række moduler som løbende kan implementeres en af gangen. Mange protokolstandarder er udviklet på denne vis og det er i grunden ikke helt tosset.

  • 0
  • 0
#18 Lars Bjerregaard

Jesper, tak for besværet med øvelsen. Det har jeg respekt for, da det er langt nemmere at sige at noget er skidt, end at demonstrere hvordan man så selv synes det skulle se ud. Så, respekt for det.

Når det er sagt, så har jeg stadig "a bad feeling" omkring denne vedtagelse i sin helhed. Den slår mig som propfyldt med huller og vagheder (er det et ord?). Men sådan er det vel med politik. F.eks. er ordet "åben" et nemt offer for voldtægt.

Jeg er enig i at ODF aldrig skulle være nævnt, da det fra starten fjerner den altafgørende troværdighed ved positivlisten. Jeg betragter det som en politisk fodfejl, men en fejl er det. Det er sagt selvom jeg personligt er stor tilhænger af ODF formatet, og det arbejde som ligger bag.

Som andre har nævnt er jeg enig i, at synet på "ikke-redigerbare" dokumenter er for snævert. PDF er oplagt, men versionerede og "frosne" (dvs. ikke-dynamiske, ændrer sig ikke i den forekommende version efter publikationsdatoen) html dokumenter er i mange sammenhænge lige så gode, eller bedre. Specielt der hvor de publiceres online selvfølgelig. PDF dokumenter er selvfølgelig bedre hvor de skal udveksles på ikke-online måder, f.eks. email.

Mener selv at datoen "1. april 2011" vil blive problematisk, da der ikke er sat en dato for, i det mindste første version, af positiv-listen. De to ting hører jo tæt sammen, så enten skulle der have været to datoer, eller ingen. Der er jo ingen tilkendegivelser overhovedet om hvornår positiv-listen er klar, eller i det mindste klar i første version.

Mener selv at punkt 6 under øvrige formater er anti-produktivt, og modsat rettet ånden i selve loven. ALLE, både borger, myndigheder, leverandører og udviklere, har brug for at vide hvad de har at holde sig til. Listen og loven er et skridt i den rigtige retning, men et punkt som nr. 6 mener jeg modarbejder dette.

Det mest positive i det er at, som du selv nævner, politikerne udstikker nogen retningslinier, men at den afgørende positivliste overlades til fagfolk, der ved hvad de snakker om. Der skal nok i årene fremover kommer en helvedes ballade ud af det, men det er vist trods alt et fremskridt.

Igen, tak for arbejdet. Keep going. Det er sgu ikke let, specielt ikke i et felt som mange folk åbenlyst brænder for :-)

(inklusive mig selv forøvrigt, mest fra open-source og friheds vinklen)

  • 0
  • 0
#19 Lars Bjerregaard

Må jeg så i øvrigt ikke have lov til generelt at efterlyse en bedre tone herinde? Skulle nødigt udvikle sig til noget der ligner andre fora (slashdot, computerworld,...) jeg (og andre) har set sig nødsaget til at flygte fra, fordi det simpelthen bliver for udlideligt, og signal-støj forholdet bliver for lavt.

Til at starte med vil jeg gerne bede folk om at afholde sig fra "name-calling" hvilket er noget af det mest destruktive, eller generelt fra at blive personlige.

Der er INGEN grund til at blive personlige, HELLER IKKE selvom man responderer til andre folk som ER blevet personlige. Det hedder integritet hvis man er i tvivl.

Der er ingen grund til at kalde folk et svineøre offentligt, heller ikke selv om de ER et svineøre. Capice?

(og lige for at afværge det åbenlyse- nej, jeg er ikke selv perfekt, men jeg prøver....)

  • 0
  • 0
#20 Poul-Henning Kamp Blogger

Der er ingen grund til at kalde folk et svineøre offentligt, heller ikke selv om de ER et svineøre. Capice?

Mntjae...

Det afhænger vist af hvilket ord der anvendes for pladsholderen "svineøre" i din påstand.

For almindelige skælsord, som "svineøre", "idiot" osv, giver jeg dig 100% ret.

Men hvis vi kommer over på abstrakte stillingsbetegnelser, f.eks "person der er betalt for at forsøge at fremme bestemte kommercielle interesser", så mener jeg faktisk det er en pligt at få dette til torvs.

Det bør aldrig være muligt for spin-doktorer, lobbyister og andre stråmænd, at afspore en debat eller beslutning, under falsk flag.

Jespers job er at fremme OOXMLs markedsandel og trods hans rimeligt ubehjælpsomme forsøg på at fremstå neutral og upartisk, har de fleste her for længst gennemskuet ham for hvad han er: I Microsofts sold.

Hvor langt han vil prostituere sig med sit amatør-spindoktori og astroturfing, er naturligvis et spørgsmål for ham og hans løncheck.

Men at det er hans løncheck det handler om, bør ikke være skjult for nogen.

Poul-Henning

  • 0
  • 0
#21 Lars Bjerregaard

PH, jeg er helt enig i din første del, og det kan sagtens gøres uden at blive personlig.

Ang. din anden del, så synes jeg den er et eksempel på at blive for personlig. Uanset om en person er "protistueret" eller ej, men jeg stærkt at man bør afholde sig fra at kalde personen det offentligt.

Uanset om man synes at ens gode hensigter og andet ligitimerer det, hører det simpelthen ikke hjemme, efter min mening. Det er lige meget om det er Jesper, Bill Gates, mig, dig, eller andre.

  • 0
  • 0
#28 Jesper Lund Stocholm Blogger

Hej Ayhan,

Jeg vil give PHK ret. Ofte når man læser dine blog-indlæg fornemmer man en eller anden skjult intention, der som regel er at advokere for djævlen. Dette indlæg er ingen undtagelse. Det lugter langt væk.

Der er nu ikke meget i mit indlæg, der er skrevet af djævlens advokat - jeg mener sådan set det hele

Du behøver ikke at gøre dig den ulejlighed at omformulere det ene og det andet. Der er ikke plads til OOXML på den famøse liste. Alle disse anstrengelser fra vores og oppositionens side er netop for at bryde den onde cirkel. OOXML er en del af denne onde cirkel.

Aha ...

Desuden hjælper det ikke på dit anstrengte ry som neutral når du angriber OSL og os andre for at sprede FUD. Fej lige for egen dør først, mister MVP.

Jeg angriber bestemt ikke dig (som person), men hvis du tidligere har fremsat beskyldninger a'la "kun Microsoft kan implementere OOXML", "Der er binære bindinger i OOXML til MS-proprietært snavs" eller "ECMA-376 er et lukket format", "Man har ikke magtet at implementere OOXML i OpenOffice.org" ... uden at have konkretiseret hvorfor, så må du da gerne føle dig ramt. Jeg synes, at det er top-fesent at komme med sådanne udtalelser - uden at kunne konkretisere dem. Min pointe med omskrivelsen af bla "demonstrationskravet" var netop at tvinge disse FUD-spredere frem på banen og få lidt mere konkret på bordet. At OSL sidst de var på krigsstien var nødt til at skrive til USA (Rob Weir) for at få hjælp er jo tankevækkende ... :o)

  • 0
  • 0
#29 Jesper Lund Stocholm Blogger

Hej Christian,

Først sætter du tvivl ved folketingets evner,

Øh - jeg har vist kun skrevet, at det åbenbart gik lidt hurtigt derinde hiun fredag. Det jeg ikke alene om at synes - bla skrev V2 jo netop om den hektiske morgen inden kl. 10:00.

så omskriver du et officelt dokumentet

Jøsses - jeg har givet mit bud på, hvordan dokumentet skulle have set ud, hvis de havde spurgt mig. Jeg har endda tydleigt markeret, hvor jeg har slettet noget og hvor jeg har tilføjet noget. hvordan du kan få det til at være en problematisk "omskrivning af et officielt dokument" er jeg totalt uforstående overfor.

Det er i mine øjne en lille smule respektløs over for alle som har deltaget i processen.

Det er skægt, at når man tænker på kommentarene på V2 efter artiklerne siden i fredags og overvejer tonen og ordbruget (ex om Michael Aarestrup om korruption etc), så er det da tankevækkende, at du synes, at [b][u]jeg[/u][/b] nu opfører mig respektløst.

:-)

  • 0
  • 0
#30 Jesper Lund Stocholm Blogger

Hej Lars,

Jesper, tak for besværet med øvelsen. Det har jeg respekt for, da det er langt nemmere at sige at noget er skidt, end at demonstrere hvordan man så selv synes det skulle se ud. Så, respekt for det.

Mange tak :o)

Jeg er ret enig i mange af dine betragtninger omkring PDF og HTML, men der er trods alt nogle ting, som HTML ikke kan levere på samme måde som PDF eller "ODF/OOXML". Alene konceptet at "alt er i samme fil" er en fordel - specielt, hvis dokumentet skal gemmes offline.

Jeg har ikke anset punkt 6 som værende problematisk - tvært imod synes jeg faktisk, at det er et ganske glimrende, pragmatisk punkt. Det siger jo nemlig, at den offentlige sektor (om ikke andet så i snitfladen til borgere og virksomheder) skal forholde sig pragmatisk til den virkelighed, der er derude. Man må derfor ikke afvise dokumenter, som "de jævnligt støder på" - selvom de ikke er i åbne formater. I mine øjne er det faktisk langt at foretrække - i forhold til den tidligere situation, hvor det offentlige kunne [b]sende[/b] dokumenter, der ikke var i åbne formater. Med konklusionspapiret ser det ud til, at denne mulighed er passé.

  • 0
  • 0
#31 Jesper Lund Stocholm Blogger

Hej Poul-Henning,

Det bør aldrig være muligt for spin-doktorer, lobbyister og andre stråmænd, at afspore en debat eller beslutning, under falsk flag.

Jespers job er at fremme OOXMLs markedsandel og trods hans rimeligt ubehjælpsomme forsøg på at fremstå neutral og upartisk, har de fleste her for længst gennemskuet ham for hvad han er: I Microsofts sold.

Hvor langt han vil prostituere sig med sit amatør-spindoktori og astroturfing, er naturligvis et spørgsmål for ham og hans løncheck.

Men at det er hans løncheck det handler om, bør ikke være skjult for nogen.

Så for søren ... jeg skrev for nogle dage siden noget i retning af, at "når jeg for flere end 5 minusser til en kommentar, så ved jeg, at jeg har fat i noget af det rigtige".

Jeg må heller føje

"... eller når jeg får PHK til at fnyse af arrigskab"

til listen.

:o)

  • 0
  • 0
#32 Lars Bjerregaard

Jesper,

Jeg har ikke anset punkt 6 som værende problematisk - tvært imod synes jeg faktisk, at det er et ganske glimrende, pragmatisk punkt. Det siger jo nemlig, at den offentlige sektor (om ikke andet så i snitfladen til borgere og virksomheder) skal forholde sig pragmatisk til den virkelighed, der er derude. Man må derfor ikke afvise dokumenter, som "de jævnligt støder på" - selvom de ikke er i åbne formater. I mine øjne er det faktisk langt at foretrække - i forhold til den tidligere situation, hvor det offentlige kunne sende dokumenter, der ikke var i åbne formater. Med konklusionspapiret ser det ud til, at denne mulighed er passé.

Her blander du de formater som det offentlige skal modtage ("ikke afvise") sammen med de formater det offentlige kunne finde på at sende ("hvor det offentlige kunne sende"). Al ære for det pragmatiske, men efter min mening ville det have været langt mere produktivt, hvis positivlisten betød: "Dette er spillereglerne for hvordan det offentlige og borgeren kan kommunikere med hinanden, og det er baseret på åbne standarder." Dvs. det offentlige forpligter sig til at kunne modtage (og sende) alle formater på listen, og dealen er til gengæld at borgerne (og andre instanser) forpligter sig til kun at sende (og kunne modtage) formater som er på listen. See? DET ville have gjort livet betragteligt nemmere for alle.

Sagen er jo at:

Herudover skal alle offentlige myndigheder fortsat – for at sikre borgerne maksimal valgfrihed – også kunne modtage dokumenter i alle gængse formater med stor udbredelse inden for anvendelsesområdet (2)

(2) Ved "gængse formater med stor udbredelse inden for et anvendelsesområde" forstås formater, som myndighederne jævnligt støder på inden for et givet område.

er en ren gummiparagraf der jo i praksis betyder "anything goes". Jeg kan love dig, at for en systemudvikler der skal udvikle f.eks. et dokumenthåndterings modul til en offentlig instans, er dette tæt på det ultimative mareridt. Det betyder jo, hvis man tager det bogstavelig, at man skal være parat til at modtage alle formater, hvad som helst. "som myndighederne jævnligt støder på" er jo betydningsløst som en definition, det kan betyde hvad som helst.

  • 0
  • 0
#33 Jesper Louis Andersen

Så for søren ... jeg skrev for nogle dage siden noget i retning af, at "når jeg for flere end 5 minusser til en kommentar, så ved jeg, at jeg har fat i noget af det rigtige".

Nu ved man ikke hvilke kriterier folk dømmer indlæg efter - men jeg flere gange overvejet hvad der ville ske hvis tilstrækkeligt med negative tilkendegivelser skjulte indlægget for andre læsere. Og samtidigt hvis vi fik trådning af kommentarer til artikler.

Det virker naturligvis ikke hvis argumentet for at tykke "pil ned" er ren ad hominem på kommentatoren - men, og det er subtilt anderledes, er kommentaren ad hominem eller bare ikke progressiv for debatten, så kunne det være interessant.

  • 0
  • 0
#34 Lars Bjerregaard

Nu ved man ikke hvilke kriterier folk dømmer indlæg efter - men jeg flere gange overvejet hvad der ville ske hvis tilstrækkeligt med negative tilkendegivelser skjulte indlægget for andre læsere. Og samtidigt hvis vi fik trådning af kommentarer til artikler.

Det virker naturligvis ikke hvis argumentet for at tykke "pil ned" er ren ad hominem på kommentatoren - men, og det er subtilt anderledes, er kommentaren ad hominem eller bare ikke progressiv for debatten, så kunne det være interessant.

Jeg vil vove den påstand at "pil-systemet" allerede har bevist sig selv ikke at virke, og at det ville være bedre uden. Det eneste jeg kunne have savnet en gang imellem er en knap der siger "skjul indlæg fra denne person", da det tit er nogle få bestemte personer man ikke gider høre på, specielt hvis de har for vane at skrive multi-siders indlæg.

  • 0
  • 0
#35 Jakob Damkjær

Det skal demonstreres, at standarden kan implementeres af alle direkte i sin helhed på flere platforme.

Blev til

Der må ikke kunne demonstreres tekniske eller specifikationsmæssige hindringer for, at enhver leverandør kan implementere standarden i sin helhed på en af denne valgt platform.

Og det er kernen i ændringen Jesper så gerne vil ha han vil lave en positiv liste om til en måske negativ men endnu ikke bevist liste.

Og alle der har fulgt med i doping ved at negativlister ikke virker. Dopingsynderene finder altid på nye tricks med stoffer der ikke er på negativlisten. Så enhver kan se at vi er bedre tjent med en positivliste for så er alt det der ikke er på den ikke tilladt. Meget nemmere at enforce og meget mere lige for udviklere og service firmaer.

  • 0
  • 0
#36 Michael Rasmussen

Så enhver kan se at vi er bedre tjent med en positivliste for så er alt det der ikke er på den ikke tilladt

En anden ulempe ved en negativliste er også, at det giver omvendt bevisførelse - MS hævder, at OOXML opfylder betingelserne for at komme på listen, hvorfor det så er overladt til øvrige aktører, at påvise OOXML ikke opfylder betingelserne!

Det er alt andet lige nemmere for aktøren, der har udviklet en standard at bevise, at standarden opfylder betingelserne for at komme på listen, end for en tredjepart at bevise det modsatte - udvikleren vil altid have større kendskab til standarden end andre aktører.

  • 0
  • 0
#37 Jesper Lund Stocholm Blogger

Hej Lars,

en ren gummiparagraf der jo i praksis betyder "anything goes". Jeg kan love dig, at for en systemudvikler der skal udvikle f.eks. et dokumenthåndterings modul til en offentlig instans, er dette tæt på det ultimative mareridt. Det betyder jo, hvis man tager det bogstavelig, at man skal være parat til at modtage alle formater, hvad som helst. "som myndighederne jævnligt støder på" er jo betydningsløst som en definition, det kan betyde hvad som helst.

jo - men alternativet er jo, at det offentlige begynder at sætte grænser for, hvordan borgerne kan kommunikere med dem. I mine øjne skal det offentlige slet ikke blande sig i det - det er borgernes suveræne ret at bestemme, hvilken måde, der synes bedst. På ganske tilsvarende vis går det offentlige endog meget langt for at sikre, at alle borgere kan modtage nødvendig information. Derfor kommunikerer det offentlige ikke udelukkende via WEB (som jo nok ellers var det billigste), men laver stadig piecer til biblioteker, laver OBS-udsendelser og lignende.

Det synes jeg er helt rimeligt.

  • 0
  • 0
#38 Jesper Lund Stocholm Blogger

Hej Jakob,

Og alle der har fulgt med i doping ved at negativlister ikke virker. Dopingsynderene finder altid på nye tricks med stoffer der ikke er på negativlisten.

Umiddelbart virker "doping-analogien" da ganske ligetil. Også i sportsverdenen er det jo således, at det ikke er atletens (her, leverandørens) ansvar at bevise, at vedkommende ikke er dopet (har fiflet med specifikationen). Det er myndighedernes ansvar at påpege dette. Og på området med dokumentformater kræver det endda ikke et laboratorium at afsløre "dopede" - man kan endda crowd-source opgaven til gud og hver mand, der måtte ønske at bidrage.

Det er totalt en win-win situation :o)

  • 0
  • 0
#39 Jesper Lund Stocholm Blogger

Hej Michael,

  • MS hævder, at OOXML opfylder betingelserne for at komme på listen, hvorfor det så er overladt til øvrige aktører, at påvise OOXML ikke opfylder betingelserne!

Min pointe er jo, at med den nuværende formuleringer vil hverken OOXML eller ODF kunne komme på listen. Siger det ikke en smule om, at kriterierne nok er forkerte?

  • 0
  • 0
#40 Jon Bendtsen

jo - men alternativet er jo, at det offentlige begynder at sætte grænser for, hvordan borgerne kan kommunikere med dem. I mine øjne skal det offentlige slet ikke blande sig i det - det er borgernes suveræne ret at bestemme, hvilken måde, der synes bedst.

Det er helt fornuftigt at det offentlige oplyser hvilke data formater de acceptere data i, også selvom at det sætter grænser for borgeren.

Du kan jo heller ikke skrive til det offentlige på serbokroatisk, hvilket også begrænser borgeren. I nogle tilfælde er det nødvendigt.

  • 0
  • 0
#41 Jon Bendtsen

Min pointe er jo, at med den nuværende formuleringer vil hverken OOXML eller ODF kunne komme på listen. Siger det ikke en smule om, at kriterierne nok er forkerte?

Det synes jeg godt nok du bruger lang tid på at sige og det fremgår ikke særlig tydeligt. Du bedes fortælle hvorfor du ikke mener de kan komme på listen.

  • 0
  • 0
#42 Christian Høier

Hej Jesper

De fleste på denne side er kommet til den konklution at dine ændringer er lavet for at OOMXL lettere kan optages på listen.

Hvorfor vil du gerne have optaget OOMXL på listen når formålet er:

For at fremme anvendelsen af software baseret på åbne standarder i det offentlige og for særligt at fremme konkurrencen på kontorsoftware samt for at sikre, at borgere og virksomheder ikke er afhængige af bestemte kontorpakker i deres kommunikation med det offentlige, gøres følgende:

For særligt at fremme konkurrencen på kontorsoftware vil det være mest naturligt at vælge ODF, da det bryder MS monopol. Hvordan vil OOMXL opnå dette?

  • 0
  • 0
#43 Jesper Lund Stocholm Blogger

Hej Jon,

Du bedes fortælle hvorfor du ikke mener de kan komme på listen.

Begge formater har problemer med at retfærdiggøre "ALLE direkte I SIN HELHED".

Begge formater jo kun implementeret "i sin helhed" af én leverandør hver.

  • 0
  • 0
#44 Jon Bendtsen

Begge formater har problemer med at retfærdiggøre "ALLE direkte I SIN HELHED".

Begge formater jo kun implementeret "i sin helhed" af én leverandør hver.

Det er jo derfor politikerne har truffet et politisk valg, netop for at:

For at fremme anvendelsen af software baseret på åbne standarder i det offentlige og for særligt at fremme konkurrencen på kontorsoftware samt for at sikre, at borgere og virksomheder ikke er afhængige af bestemte kontorpakker i deres kommunikation med det offentlige, gøres følgende:

Derfor virker det mærkeligt, at man fra Folketingets side giver ekspertudvalget og OIO-komiteen ansvar for dannelse af listen - men samtidig blander sig i et enkelt formats apriori-placering på listen.

Nej, det virker ikke spor mærkeligt. Politikerne har truffet et politisk valg, det er det vi har valgt dem til.

  • 0
  • 0
#45 Eskild Nielsen

Begge formater jo kun implementeret "i sin helhed" af én leverandør hver.

Der er så den forskel, at det ene formats leverandør har sin løsning implementeret på alle de platforme, som i praksis er i brug når dokumenter skal dannes.

Og da den løsning er LGPL, kan den uden licensomkostninger indgå i mange andre leverandørers produkter - hvilket den så også gør.

/esni

  • 0
  • 0
#47 Jon Bendtsen

Nej, det virker ikke spor mærkeligt. Politikerne har truffet et politisk valg, det er det vi har valgt dem til.

Desværre så skulle de have været endnu skrappere da de træf beslutningen. Der burde kun have været disse 4 formater:

ren iso-8859-1 tekst HTML4 måske 5, naturligvis i strict PDF ODF

  • 0
  • 0
#48 Jesper Lund Stocholm Blogger

Hej Jon,

Nej, det virker ikke spor mærkeligt. Politikerne har truffet et politisk valg, det er det vi har valgt dem til.

Vær opmærksom på ordene i konklusionspapiret. Det er for mig tydeligt, at listens "medlemmer" vælges efter en teknisk/ekspertmæssig vurdering af først ekspertudvalget og OIO-kommiteen og herefter afpolitikerne. Men der er nogle kriterier for overhovedet at komme i betragtning til listen - og disse er skitseret ovenfor. Der er altså ikke tale om, at "hvis en standard opfylder kravene, så er den automatisk på listne". Det er mere i retning af "hvis en standard opfylder kravene, så [b]kan[/b] den komme i betragning".

... eller med andre ord: "hvis en standard [b]ikke[/b] opfylder kravene, så kan den [b]ikke[/b] komme på listen".

Det virker da meget rimeligt på mig.

  • 0
  • 0
#49 Jesper Lund Stocholm Blogger

Hej Christian,

De fleste på denne side er kommet til den konklution at dine ændringer er lavet for at OOMXL lettere kan optages på listen.

Det er muligt, at "vox populi" synes dette, men sandheden er mere, at jeg er af den holdning, at vi skal stille krav, der giver mening og rent faktisk kan opfyldes af nogen. Jeg mener også, at opfyldelsen af krav skal vurderes på samme måde - uanset leverandør. Derfor må en grund til afvisning af fx OOXML kunne anvendes på nøjagtig samme vis på ODF, og hvis kravet heller ikke kan opfyldes af ODF, så må man acceptere, at også ODF afvises.

  • 0
  • 0
#50 Jesper Lund Stocholm Blogger

Hej Eskild,

Der er så den forskel, at det ene formats leverandør har sin løsning implementeret på alle de platforme, som i praksis er i brug når dokumenter skal dannes.

Og da den løsning er LGPL, kan den uden licensomkostninger indgå i mange andre leverandørers produkter - hvilket den så også gør.

Og? Det ændrer stadig ikke ved, at der kun er én implementering af ODF "i sin helhed". Det er jo bla. derfor interoperabilitet via ODF er god - hvis man bruger Suns kildekode, men er "moderat dårlig", hvis man går på tværs af [i]implementeringer af ODF-understøttelse[/i] og ikke kun [i]applikationer med ODF-understøttelse[/i].

Jeg antager, at grunden til den oprindelige formulering i aftalen er, at man ikke vil risikere, at selvom specifikationen er tilgængelig for alle, så kræver implementering "i sin helhed" af specifikationen en viden, som kun én leverandør besidder.

At smække en ny brugerflade på LGPL-klumpen fra OOo ændrer ikke ved, at det er Suns implementering af ODF, der anvendes.

  • 0
  • 0
#52 Jesper Lund Stocholm Blogger

Hej Per,

Er ODF kun implementeret af én leverandør? OpenOffice? Hvad med Lotus Symphony? :) Jeg ved ikke om KOffice 2.0 har en komplet ODF-implementation, men den er da også et godt bud.

Lotus Symphony anvender OOo og har via Eclipse (som jeg forstår det) fået smækket en ny brugerflade på. Det er altså Suns ODF-implementering, der ligger til grund for Lotus Symphony.

KOffice 2.0 er på ingen måde en komplet implementering af ODF.

  • 0
  • 0
#53 Christian Høier

Jeg mener også, at opfyldelsen af krav skal vurderes på samme måde - uanset leverandør. Derfor må en grund til afvisning af fx OOXML kunne anvendes på nøjagtig samme vis på ODF, og hvis kravet heller ikke kan opfyldes af ODF, så må man acceptere, at også ODF afvises.

Uanset hvad du mener ændre det jo ikke på den politiske beslutning:

For at fremme anvendelsen af software baseret på åbne standarder i det offentlige og for særligt at fremme konkurrencen på kontorsoftware samt for at sikre, at borgere og virksomheder ikke er afhængige af bestemte kontorpakker i deres kommunikation med det offentlige, gøres følgende:

og i den hensende hvordan vil OOXML særligt fremme konkurrencen på kontorsoftware?

  • 0
  • 0
#54 Jon Bendtsen

Hvorfor ikke bruge UTF-8 som resten af verden? Det var jo i øvrigt netop UTF-8 som Norge nu kræver anvendt.

Er UTF-8 en ISO standard? Min opfattelse var at politikerne krævede at det var en ISO standard. Men okay, HTML er nok ikke så vi godt kræve UTF-8.

  • 0
  • 0
#55 Jesper Lund Stocholm Blogger

Hej Jon,

og i den hensende hvordan vil OOXML særligt fremme konkurrencen på kontorsoftware?

At OOXML er en åben standard og beskriver dokumentformatet (opførslen) i den kontorpakke, der anvendes af 90% af verdens brugere af kontorpakker?

  • 0
  • 0
#57 Jon Bendtsen

At OOXML er en åben standard og beskriver dokumentformatet (opførslen) i den kontorpakke, der anvendes af 90% af verdens brugere af kontorpakker?

Så fremmer det jo netop ikke konkurrencen at vælge det format. Derimod vil man bare give en fordel til Microsoft ved at vælge at tillade OOXML.

  • 0
  • 0
#58 Christian Høier

Hej Jesper

[qoute]At OOXML er en åben standard og beskriver dokumentformatet (opførslen) i den kontorpakke, der anvendes af 90% af verdens brugere af kontorpakker?[/qoute]

Så det er altså særligt fremmende for konkurrencen at MS sidder på 90% på market ???

  • 0
  • 0
#59 Jesper Lund Stocholm Blogger

Hej Christian (og Jon),

Så det er altså særligt fremmende for konkurrencen at MS sidder på 90% på market ???

Nej - men det er bestemt fremmende for konkurrencen, at dokumentformatet i kontorpakken med 90% markedsandel nu er dokumenteret og vedligeholdt i en åben proces.

Men er dette ikke et sidespor til selve artiklen?

Siden I nu synes, at det er så åbenlyst tåbeligt, at jeg stiller spørgsmålstegn ved OOXMLs placering på listen (efter gældende krav) og (ikke mindst, tilsyneladende) ditto for ODF - kunne I to friske fyre så ikke lynhurtigt [b]demonstrere[/b], at ODF kan implementeres af alle i sin helhed?

  • 0
  • 0
#60 Jon Bendtsen

Nej - men det er bestemt fremmende for konkurrencen, at dokumentformatet i kontorpakken med 90% markedsandel nu er dokumenteret og vedligeholdt i en åben proces.

Det kan vi jo også opnå ved at de bruger ODF ;-)

Men er dette ikke et sidespor til selve artiklen?

Næh

Siden I nu synes, at det er så åbenlyst tåbeligt, at jeg stiller spørgsmålstegn ved OOXMLs placering på listen (efter gældende krav) og (ikke mindst, tilsyneladende) ditto for ODF - kunne I to friske fyre så ikke lynhurtigt demonstrere, at ODF kan implementeres af alle i sin helhed?

Nej, for det er et politisk valg at ODF skal være på listen.

  • 0
  • 0
#61 Christian Høier

Hej Jesper

Det er meget simpelt. Dokumentet er en politisk beslutning og ikke en teknisk diskussion

Derfor virker det (som du selv siger) ”åbentlys tåbeligt” at du bliver ved med at fremhæve OOXML som en kandidat, da det format ikke vil ændre på konkurrence forholdene.

Du kan så være enig eller uenig i politikken, men det er uden betydning i denne sammenhæng.

ODF vil opfylde det politiske målsætning, det vil OOXML ikke.

Det har ikke noget med retfærdighed

  • 0
  • 0
#62 Christian Høier

Hej Jesper

Jeg kan ser et du er lægger stor vægt på implementering og dokumentation

kunne I to friske fyre så ikke lynhurtigt demonstrere, at ODF kan implementeres af alle i sin helhed?

Så lad os tage tingene 1 skridt af gangen.

Når nu doc og docx er dagens standard, så må ODF da i dine øjne da være et klart bedre valg. Her har du en format som har en ISO standard og er betydeligt mere vel dokumenteret.

Er det ikke et stort skridt i den rigtige retning?

  • 0
  • 0
#63 Eskild Nielsen

At OOXML er en åben standard og beskriver dokumentformatet (opførslen) i den kontorpakke, der anvendes af 90% af verdens brugere af kontorpakker?

90 % er vist kun hvis man lægger aller versionerne af MS office sammen?

Er det ikke kun MS Office 2007 og senere der har OOXML?

  • 0
  • 0
#64 Jesper Lund Stocholm Blogger

Hej Jon,

Det kan vi jo også opnå ved at de bruger ODF ;-)

Tjo - men det har så nogle uheldige konsekvenser, som brug af OOXML ikke giver.

Nej, for det er et politisk valg at ODF skal være på listen.

Men kan jeg så konkludere, at du ikke ser det som et problem, at ODF er på listen - selvom den ikke opfylder de krav, som andre skal opfylde?

Det er jo lidt en catch-22 du har lavet:

Leverandør: jeg vil gerne kunne bruge format x Offentlig instans: Ja, men så skal formatet være på listen Leverandør: Jamen, ingen kan opfylde de krav, der er på listen Offentlig instans: Tja - men så kan du ikke komme på listen Leverandør: Hvordan skal jeg så bruge mit format? Offentlig instans: Det skal først være på listen

...

Det er jo en super genial måde at sikre, at ODF bliver eneste valg på listen - selvom man udadtil snakker om muligheden for at komme på listen. Man vælge ganske enkelt ODF, og så laver man en "krav-liste", der ikke kan opfyldes af nogen ... og heller ikke ODF.

Det er jo samme taktik, som diskoteksejere bruger overfor indvandrere. Man tillader alle grisefarvede danskere at komme ind, men indvandrere skal overholde en række krav for at komme ind - og vel at mærke krav, som ikke kan opfyldes.

... hmm ... "dokumentformatracist" ... har jeg opfundet et nyt ord?

:o)

  • 0
  • 0
#65 Jesper Lund Stocholm Blogger

Hej Christian,

Når nu doc og docx er dagens standard, så må ODF da i dine øjne da være et klart bedre valg. Her har du en format som har en ISO standard og er betydeligt mere vel dokumenteret.

Du taler udenom.

Du må meget gerne demonstrere, at ODF kan implementeres af alle i sin helhed.

(det kan da ikke være så svært?)

  • 0
  • 0
#68 Jesper Lund Stocholm Blogger

Hej Jon,

Det passer mig fint, for det er alligevel smartest med kun et format til samme type opgave.

Jatak, det er jeg klar over - men det er jo ikke det "politiske valg" folketinget har foretaget (som du jo hyldede før).

Med folketingets beslutning har man endegyldigt smækket det sidste søm i ligkisten for en "ét format-strategi", for man har tydeligt valgt at fokusere mere på "åbne standarder" end på en "Highlander-tilgang".

Set i det lys - synes du så, at det giver mening med kvalifikationskrav, der er for forskellige for de forskellige formater? Synes du, at det giver mening at have ODF på listen - når den nu ikke opfylder de krav, som andre formater skal?

(altså det der med åbenhed, mulighed for alle for at implementere i sin helhed etc)

  • 0
  • 0
#69 Michael Rasmussen

synes du så, at det giver mening med kvalifikationskrav, der er for forskellige for de forskellige formater

Det har man jo sådan set politisk vedtaget qua formuleringen af funktionsluftet, der jo giver først optagne format på listen ret til at sætte omfanget af funktionsluftet.

  • 0
  • 0
#70 Jon Bendtsen

Jatak, det er jeg klar over - men det er jo ikke det "politiske valg" folketinget har foretaget (som du jo hyldede før).

Før var det nok bare mere en konstatering af hvad beslutningen var. Jeg er ikke enig med dem og ville have valgt noget andet.

Med folketingets beslutning har man endegyldigt smækket det sidste søm i ligkisten for en "ét format-strategi", for man har tydeligt valgt at fokusere mere på "åbne standarder" end på en "Highlander-tilgang".

Nej, det er noget vrøvl, det er ikke endegyldigt. Beslutningen kan tages om senere. Jeg synes stadig at 1 åben standard er den bedste løsning.

Set i det lys - synes du så, at det giver mening med kvalifikationskrav, der er for forskellige for de forskellige formater? Synes du, at det giver mening at have ODF på listen - når den nu ikke opfylder de krav, som andre formater skal?

(altså det der med åbenhed, mulighed for alle for at implementere i sin helhed etc)

Jesper, hold nu op. Du tror da vel ikke på at du kan overbevise nogen som helst om at ODF ikke er åben og med rig mulighed for alle at implementere i sin helhed?

  • 0
  • 0
#71 Jakob Damkjær

"Umiddelbart virker "doping-analogien" da ganske ligetil. Også i sportsverdenen er det jo således, at det ikke er atletens (her, leverandørens) ansvar at bevise, at vedkommende ikke er dopet (har fiflet med specifikationen). Det er myndighedernes ansvar at påpege dette. Og på området med dokumentformater kræver det endda ikke et laboratorium at afsløre "dopede" - man kan endda crowd-source opgaven til gud og hver mand, der måtte ønske at bidrage.

Det er totalt en win-win situation :o)"

Og det er derfor negativ lister ikke virker.

Hvis vi bibeholder en positiv liste så vil alt andet ikke være tilladt og det vil give en meget enklere og mere enforcebar løsning.

Hvis vi havde en positivliste med kosttilskud og medicinske behandlinger som atleter måtte bruge inden en konkurance så villle det være så nemt at hitte rede i. fx Atlet A har brugt "superkondis" kosttilskud mindre end 3 måneder inden konkurancen. Superkondis kosttilskud er ikke på positiv listen ergo er atlet A udelukket.

som det er nu med negativ lister så skal man først fanges i en doping test (som ikke bliver lavet på alle deltagere) og der skal være tydeligt nok resultat til at man kan få et gentagbart resultat på a og b prøver og derefter kommer alle bortforklaringerne (jeg vidste det ikke, det var til min hund og jeg kom til at spise det i en brandert, min træner sagde det var vitamin indsprøjtninger osv osv osv)

Hvilket system vil man helst ha... jeg vælger positivlisten.

Mystisk nok vil ms psykofanter helst ha negativ listen for de har rigeligt tid til at fjumre rundt i retsale mens bizzness as usual forsætter..... surprise

/Jakob

PS! Bare så vi får doping analogien helt på plads... folk der er dopingdømte bliver mærkeligt nok altid udtaget til prøve når de har overstået deres udelukkelse.... ring a bell anyone...

Du ved på samme måde som firmaer der allerede er blevet dømt for konkurancelovgivnings brud er selvskrevet til en liste over mistænkte når en ny sag kommer op... mystisk.

  • 0
  • 0
#72 Kristian Larsen

Jeg er lidt forundret over de der her i tråden går efter manden og ikke bolden.

Når det så er sagt: Lotus Symphony er en komplet fork af OOo. IBM er vidst ved at backporte nogle opdateringer fra 2.0 og 3.0 træet til deres fork. Mao. er Symphony ligeså meget sin egen implementering af ODF som som AIX, HP-UX og Solaris er hver deres implementering af System V.

Derudover findes en række eksempler for readere som kan håndtere ODF og Google App's kan vidst også både importere og eksportere i ODF.

Så lige til lidt quoteri:

Tjo - men det har så nogle uheldige konsekvenser, som brug af OOXML ikke giver.

Jeg tillader mig at formode at du dermed mener redigering af legacy dokumenter (hvilket vidst også er dit argument for at have ændret holdning fra at kun OOXML S skulle bruges til at både T og S skulle bruges).

Og svaret her er meget simpelt - fra skærings datoen (X), skal dokumenter det offentlige skal udveksle med andre instanser og/eller borgere være konverteret til det nye format. Alle andre dokumenter kan lagres således at de kan eksporteres til et statisk format (f.eks. PDF). Mao. er det altså en begrænset submængde af dokumenter der skal konverteres og dette ville mange af dem alligevel skulle for at komme i en OOXML S udgave. Og eftersom det der ligger i T delen af OOXML er "bagage" fra tidligere kan dette i en fremsynet kontekst skrottes således at implementeringen fremadrettet vil være noget simplere.

Compat-pack fra Microsoft giver OOXML-understøttelse til Microsoft Office 2000 og frem.

Nej, den giver Office XP og Office 2003 standard programmerne (dvs. excel, powerpoint og word) mulighed for at læse ECMA proposal. Hvor godt det virker idag ved jeg ikke, men oprindeligt virkede det dårligere end konvertering mellem OOXML og ODF. Der kan også konverteres DOC dokumenter til noget der mindrer om ECMA proposal MEN det kræver så at du har visse opdateringer til Office 2007 for at kunne læse dette (dvs. Office 2007 RTM kan ikke læse Office 2003 compat. dokumenter ordentligt).

Generelt til diskussionen: Det giver selvfølgelig mening at definere mindst 1 standard på den nye liste, da funktionsloftet dermed bliver defineret. Det giver også mening at der sikres at der ikke er random hindringer for f.eks. at implementere et format på en platform med FOSS licens - AFAIK er det stadig ikke muligt at bruge informationen om hvordan legacy doc formaterne fungerede på en platform med åben kildekode jf. de betingelser MS stiller informationen til rådighed med. Og eftersom den information delvist er påkrævet for at kunne implementere OOXML T fuldt ud er den del af standarden allerede afvist der udfra denne betingelse, men vil ikke være det med omskrivningen, hvilket vel netop er pointen? Og så er vi tilbage til: Omskrivningen er til for at OOXML kan komme på listen.

Diskussionen er nemlig ikke om ODF kan komme på listen, fordi det ER den - men som sædvanlig danser du ved siden af når du bliver konfronteret med dette, ligesom du givetvis vil tage en lille bid af mit indlæg og bide dig fast i fremfor at diskutere essensen, og det er mildt sagt irriterende :(

  • 0
  • 0
#73 Jon Bendtsen

Diskussionen er nemlig ikke om ODF kan komme på listen, fordi det ER den - men som sædvanlig danser du ved siden af når du bliver konfronteret med dette, ligesom du givetvis vil tage en lille bid af mit indlæg og bide dig fast i fremfor at diskutere essensen, og det er mildt sagt irriterende :(

Det irriterer også os andre, og så skriver vi det til Jesper, og det er det som du tror er at vi kører på ham:

Jeg er lidt forundret over de der her i tråden går efter manden og ikke bolden.

Det gør vi ikke, men vi er trætte af at Jesper:

som sædvanlig danser Jesper ved siden af når Jesper bliver konfronteret med dette, ligesom Jesper givetvis vil tage en lille bid af alles indlæg og bide sig fast i fremfor at diskutere essensen, og det er mildt sagt irriterende :(

;-)

  • 0
  • 0
#74 Ayhan Binici

som sædvanlig danser Jesper ved siden af når Jesper bliver konfronteret med dette, ligesom Jesper givetvis vil tage en lille bid af alles indlæg og bide sig fast i fremfor at diskutere essensen, og det er mildt sagt irriterende :(

Er det ikke hvad alle spindoktorer er gode til?

  • 0
  • 0
#76 Jesper Lund Stocholm Blogger

Hej Jon,

Nej, det er noget vrøvl, det er ikke endegyldigt. Beslutningen kan tages om senere.

Ja - men et fuldstændigt enigt Folketing har nu smidt "ét-format-idéen" i graven. Når man tænker på, hvor lang tid man har brugt på at finde en aftale og hvor meget energi ordførerne har brugt på denne sag, så tvivler jeg meget på, at de vil røre aftalen med en ildtang de næste år. Derfor er den virkelighed vi arbejder med i dag ikke en "ét-formats-politik" men en "flerformats-politik".

Jesper, hold nu op. Du tror da vel ikke på at du kan overbevise nogen som helst om at ODF ikke er åben og med rig mulighed for alle at implementere i sin helhed?

Nej da, men som aftalen er nu er det heller ikke min opgave. Det er derimod min (og din og alle jer andres) opgave - hvis vi ønsker at ODF skal fremgå af listen - at demonstrere, at ODF kan implementeres af alle i sin helhed.

Min påstand er her, at det ikke kan lade sig gøre for ODF og heller ikke for OOXML.

  • 0
  • 0
#78 Jesper Lund Stocholm Blogger

Hej Christian,

Jeg er lidt forundret over de der her i tråden går efter manden og ikke bolden.

Så må du være ny herinde, for sådan er det. Når argumenterne fattes, så er det lang nemmere at smide "MVP-kortet" eller gloser som "astroturfing" etc.

"When in Rome ..." :o)

Lotus Symphony er en komplet fork af OOo. IBM er vidst ved at backporte nogle opdateringer fra 2.0 og 3.0 træet til deres fork. Mao. er Symphony ligeså meget sin egen implementering af ODF som som AIX, HP-UX og Solaris er hver deres implementering af System V.

Det er nyt for mig, at IBM har lavet så store ændringer i ODF-motoren fra Sun, at den kan karakteriseres som "egen ODF-implementering". Har du en reference til din påstand eller er det blot gisninger?

(jeg troede faktisk, at IBMs bidrag/backport til OOo primært var på GUI-siden)

Derudover findes en række eksempler for readere som kan håndtere ODF og Google App's kan vidst også både importere og eksportere i ODF.

Google Docs er meget, meget, meget langt fra at kunne betragtes som en ODF-implementering "i sin helhed".

Jeg tillader mig at formode at du dermed mener redigering af legacy dokumenter (hvilket vidst også er dit argument for at have ændret holdning fra at kun OOXML S skulle bruges til at både T og S skulle bruges).

Nej - argumentet var nu et lidt andet, men skal vi ikke lade den ligge i dag?

Nej, den giver Office XP og Office 2003 standard programmerne (dvs. excel, powerpoint og word) mulighed for at læse ECMA proposal. Hvor godt det virker idag ved jeg ikke, men oprindeligt virkede det dårligere end konvertering mellem OOXML og ODF.

Aha - så når Microsoft (på den side jeg henviser til) skriver, at

"By installing the Compatibility Pack in addition to Microsoft Office 2000, Office XP, or Office 2003, you will be able to [b]open[/b], [b]edit[/b], and [b]save[/b] files using the file formats in newer versions of Word, Excel, and PowerPoint ."

... så lyver de?

Der kan også konverteres DOC dokumenter til noget der mindrer om ECMA proposal MEN det kræver så at du har visse opdateringer til Office 2007 for at kunne læse dette (dvs. Office 2007 RTM kan ikke læse Office 2003 compat. dokumenter ordentligt).

Hvilke opdateringer er det? Og hvad mener du med "Office 2007 RTM" - mener du den version af Office 2007, der kom umiddelbart før lanceringen af Microsoft Office 2007 sidst i 2006?

AFAIK er det stadig ikke muligt at bruge informationen om hvordan legacy doc formaterne fungerede på en platform med åben kildekode jf. de betingelser MS stiller informationen til rådighed med.

Licensmæssigt er dokumentationen for de binære dokumentformater stillet til rådighed under OSP, dvs den samme licens som Microsoft har dækket OOXML og ODF med.

Og eftersom den information delvist er påkrævet for at kunne implementere OOXML T fuldt ud er den del af standarden allerede afvist der udfra denne betingelse

Hvilke dele af OOXML er det du hentyder til?

Diskussionen er nemlig ikke om ODF kan komme på listen, fordi det ER den - men som sædvanlig danser du ved siden af når du bliver konfronteret med dette, ligesom du givetvis vil tage en lille bid af mit indlæg og bide dig fast i fremfor at diskutere essensen, og det er mildt sagt irriterende :(

Nu har jeg forsøgt at svare dig på stort set hele dit indlæg, så nu håber jeg, at jeg ikke har glemt noget væsentligt (og at du ikke mener, at jeg bider mig fast i en lille bid). Jeg håber derfor også, at du vil svare på de opklarende spørgsmål jeg har stillet dig.

Dit indlæg er jo i øvrigt et godt eksempel på idéen med min omskrivning. Vi har jo snart diskuteret i 3 år, og det kan sgu ikke være rigtigt, at I ikke endnu kan komme med konkrete eksempler på jeres påstande. I dit indlæg bruger du formuleringer som:

"er vidst ved" "kan vidst også" "Hvor godt det virker [...] ved jeg ikke" "at du har visse opdateringer" "AFAIK er det stadig ikke muligt at" "eftersom den information delvist er påkrævet"

Hvorfor bruger du alle disse løse formuleringer? Det er jo ikke politik vi taler om her - det er tekniske ting, der let bør kunne konkretiseres ... hvis man ellers har den fornødne viden.

Jeg mener - det er vel ikke ting, du har fundet på, så enten har du selv undersøgt dem - og bør derfor have informationen "at your fingertips" eller også har du læst det et sted - og bør have links til stederne "at your fingertips".

Og endelig: Naturligvis bør ODF være på listen - det turde være klart for enhver. Men jeg er samtidig af den opfattelse, at eftersom vi alle er lige for Vorherre, bør det også gælde for dokumentformater. Hvis man bruger et krav til at diskvalificere et format, så bør ODF naturligvis også falde - hvis den heller ikke kan overholde kravet.

Jeg kan ikke forstå, at folk kan være uenige i dette.

  • 0
  • 0
#79 Peter Favrholdt

Hej Jesper,

Jeg kan ikke forstå, at folk kan være uenige i dette.

Prøv at forstå at vi er nogen der ønsker ét og kun ét format - og dette format skal være åbent og simpelt nok til at andre end Microsoft kan implementere det.

Kan du i øvrigt forklare mig hvorfor MS Office kun kan køre på MS Windows (jeg ved godt at der er en Mac MS Office - men den er ikke fuldt kompatibel med MS Windows versionen), mens OpenOffice kan køre på MS Windows, Mac, og Linux (og er fuldt kompatibel)?

Er det fordi Microsoft ikke kan finde ud af at lave ordentlig software eller er det fordi de ikke vil (af forretningsmæssige grunde)?

Og: synes du det er ligegyldigt for diskussionen af valg af standardformat at OpenOffice er gratis at bruge på alle disse platforme (og dermed tillader disse at konkurrere frit) mens MS Office har bindinger til andre MS-produkter?

mvh. Peter

  • 0
  • 0
#80 Michael Rasmussen

Hvorfor bruger du alle disse løse formuleringer? Det er jo ikke politik vi taler om her - det er tekniske ting, der let bør kunne konkretiseres ... hvis man ellers har den fornødne viden

Jesper, er det ikke netop essensen af hele postyret i sin enkelhed?

Der findes ingen open reference implementation af OOXML i sin helhed - med åben menes her adgang til kildekode - hvorfor disse spørgsmål ikke kan besvares entydigt. Dette gælder både argumenter for at OOXML bør være på listen, såvel som argumenter for at OOXML ikke bør være på listen. Der er vel en grund til at standarder standardiseret gennem IETF, har været så succesfulde, nemlig at to uafhængige åbne reference implementationer skal findes på to uafhængige platforme!

  • 0
  • 0
#81 Carsten Sonne

Kravet om interoperabilitet er langt det vigtigste krav på listen.

Interoperabel inden for funktionalitetsloftet med andre standarder på listen.

Såfremt funktionalitetsloftet bliver defineret tilstrækkeligt højt til at favne almene brugeres behov, så er det fuldstændigt ligegyldigt om der står ODF, OOXML eller whatever på listen.

Bare man som borger frit kan konverterer et dokument til et format hans/hendes software kan bruge, så er diverse teknikaliteter uinteressante for borgeren, herunder hvad filformatet er.

Der er det der er hele kernen i spørgsmålet om åbne standarder. Ikke ODF, DOCX, DOC el. OOXML. Der er er et spørgsmål om frihed til at vælge software, ikke om filformater etc.

  • 0
  • 0
#82 Jesper Lund Stocholm Blogger

Hej Peter,

Prøv at forstå at vi er nogen der ønsker ét og kun ét format

Ja - det forstås, men det er nu engang ikke den virkelidhed vi lever i. "Ét-format politikken" er lagt i graven, og omend den sidste nagle ikke er slået i kisten og beslutningen kan omgøres engang i fremtiden, så er det den virkelighed vi må forholde os til.

Kan du i øvrigt forklare mig hvorfor MS Office kun kan køre på MS Windows (jeg ved godt at der er en Mac MS Office - men den er ikke fuldt kompatibel med MS Windows versionen), mens OpenOffice kan køre på MS Windows, Mac, og Linux (og er fuldt kompatibel)?

Jeg kan ikke forklare dig det - den viden har jeg ikke - men jeg kan da give et bud:

Microsoft har ikke haft et "forretningsmæssigt incitament" til at udvikle Office til Linux. Det er jo gået ganske godt med at få skrabet grunker ind i Redmond udelukkende med Windows-understøttelse. At man har haft en "den rører jeg ikke med en ildtang"-holdning til Linux i Redmond skal man nok heller ikke helt afvise.

En grund til at Sun har lavet OpenOffice.org til så mange platforme som den er skyldes sikkert, at de har været nødt til det for at opnå kritisk masse. Som "den lille spiller" ifht Microsoft Office har de måttet spille på andre værktøjer end netværkseffekter, og derfor har de sigtet så bredt som muligt.

Fælles for dem begge er: det drejer sig om kroner og ører.

Og: synes du det er ligegyldigt for diskussionen af valg af standardformat at OpenOffice er gratis at bruge på alle disse platforme

Ja.

Godkendelse af et dokumentformat skal primært bero på "værdiskabelse", "relevans i markedet" samt om specifikationen er god nok og ikke teknisk/juridisk/etc udelukker nogen spillere på markedet. Om en leverandør vælger at bero på en forretningsmodel, der er OSS eller om den er CSS er et valg den enkelte leverandør må foretage. Al erfaring viser jo, at der [b]vil[/b] blive lavet OSS-implementeringer, så at kræve det som udgangspunkt er i mine øjne irrelevant.

  • 0
  • 0
#83 Jesper Lund Stocholm Blogger

Hej Michael,

Der findes ingen open reference implementation af OOXML i sin helhed - med åben menes her adgang til kildekode - hvorfor disse spørgsmål ikke kan besvares entydigt.

Du skyder forbi!

Kristian skrev om (min formulering)

"IBMs modifikationer til ODF-implementering fra Sun samt back-porting af disse."

Kilde?

"Dele af OOXML kræver kendskab til de binære dokumentformater"

Kilde?

Specielt sidstnævnte må være lige til at svare på. Det må jo nemlig betyde, at der er elementer eller attributter i OOXML, der er beskrevet på en sådan måde, at man ikke kan implementer dem uden at kende de binære dokumentformater.

Er det for meget forlangt at bede om dokumentation for disse udtalelser?

Dette gælder både argumenter for at OOXML bør være på listen, såvel som argumenter for at OOXML ikke bør være på listen. Der er vel en grund til at standarder standardiseret gennem IETF, har været så succesfulde, nemlig at to uafhængige åbne reference implementationer skal findes på to uafhængige platforme!

Tjo - men det kan hverken ODF eller OOXML jo opfylde. IETFs formulering er jo ret tæt på beslutningen i folketinget, så det ændrer jo ikke noget.

  • 0
  • 0
#84 Christian Nobel

Bare man som borger frit kan konverterer et dokument til et format hans/hendes software kan bruge, så er diverse teknikaliteter uinteressante for borgeren, herunder hvad filformatet er.

Altså jeg køber bare en bil og kaster mig ud i trafikken, uden at kere mig om færdselsloven?

Der er det der er hele kernen i spørgsmålet om åbne standarder. Ikke ODF, DOCX, DOC el. OOXML. Der er er et spørgsmål om frihed til at vælge software, ikke om filformater etc.

Temmelig selvmodsigende må jeg sige, for åbne standarder drejer sig jo lige præcis om filformater, og ikke programmer!

/Christian

  • 0
  • 0
#85 Jesper Lund Stocholm Blogger

Hej Carsten,

Såfremt funktionalitetsloftet bliver defineret tilstrækkeligt højt til at favne almene brugeres behov, så er det fuldstændigt ligegyldigt om der står ODF, OOXML eller whatever på listen.

Åh hvor ville jeg ønske, at folk ville stoppe med at snakke om funktionalitetsloftet ... mage til luftigt begreb skal man lede længe efter. Det er fulstændigt umuligt at konkretisere noget som helst i begrebet.

:o)

  • 0
  • 0
#86 Christian Nobel

Ja - det forstås, men det er nu engang ikke den virkelidhed vi lever i. "Ét-format politikken" er lagt i graven, og omend den sidste nagle ikke er slået i kisten og beslutningen kan omgøres engang i fremtiden, så er det den virkelighed vi må forholde os til.

Du prøver i hvert fald ihærdigt med hammer og søm!

Herudover så mener jeg slet og ret at OOXML er noget bras, da det er tydeligt at den monster store specifikation er et udtryk der afspejler at MSO er et kludetæppe af programmer, og ikke et produkt:

Formattering af farver og alignment OOXML: [code=xml]OOXML Text OOXML Sheet OOXML Presentation [/code]

Formattering af farver og alignment ODF: [code=xml]ODF Text ODF Sheet ODF Presentation [/code]

/Christian

#87 Carsten Pedersen

@Lars Bjerregaard 6. februar 2010 16:16

Det eneste jeg kunne have savnet en gang imellem er en knap der siger "skjul indlæg fra denne person", da det tit er nogle få bestemte personer man ikke gider høre på, specielt hvis de har for vane at skrive multi-siders indlæg.

http://userscripts.org/scripts/show/50407

  • virker glimrende her, 45 indlæg skjult i alene i denne tråd.
  • 0
  • 0
#88 Carsten Sonne

Altså jeg køber bare en bil og kaster mig ud i trafikken, uden at kere mig om færdselsloven?

Jeg forstår ikke analogien.

Temmelig selvmodsigende må jeg sige, for åbne standarder drejer sig jo lige præcis om filformater, og ikke programmer!

Tværdigmod. Åbne standarder drejer sig om interoperabilitet.

Åh hvor ville jeg ønske, at folk ville stoppe med at snakke om funktionalitetsloftet ... mage til luftigt begreb skal man lede længe efter. Det er fulstændigt umuligt at konkretisere noget som helst i begrebet.

Funktionalitet kan defineres som krav. Det er den måde et stykke software specificeres på i en kontrakt. Mere luftigt er det ikke.

[b]Kom nu ud af skyttegravene og ind i kampen![/b]

  • 0
  • 0
#89 Kristian Larsen

Det er nyt for mig, at IBM har lavet så store ændringer i ODF-motoren fra Sun, at den kan karakteriseres som "egen ODF-implementering". Har du en reference til din påstand eller er det blot gisninger?

(jeg troede faktisk, at IBMs bidrag/backport til OOo primært var på GUI-siden)

De har taget hele kodebasen af OOo version 1.3 mener jeg det var, og udfra den lavet en lang række ændringer, ikke mindst det nye eclipse baserede UI men også ift. import/eksport filtre osv.

Så Symphony som helhed er en fork ift. OOo som helhed - jeg kan af gode grunde ikke udtale mig specifikt om deres ODF implementering andet end at den toler ODF noget bedre end en OOo 1.3 :).

Aha - så når Microsoft (på den side jeg henviser til) skriver, at

"By installing the Compatibility Pack in addition to Microsoft Office 2000, Office XP, or Office 2003, you will be able to open, edit, and save files using the file formats in newer versions of Word, Excel, and PowerPoint ."

... så lyver de?

Office 2007 som ift. da det blev skrevet er "Newer versions" bruger vel også stadig ECMA proposal ellers vil jeg da gerne have din dokumentation for andet.

Og det fungerer stadig på den måde at open er == import (ie. konvertering) og save er export == konvertering, og når nu dokumentet ER konverteret er edit vel åbenlys eller?

Og pakken kan stadig kun bruges til Office XP og 2003 - det står iøvrigt meget tydeligt på den side, så nej Office 2000 kan ikke.

Google Docs er meget, meget, meget langt fra at kunne betragtes som en ODF-implementering "i sin helhed".

I så fald, eftersom den gør det samme som compat. pack [import og export af/til odf] er det altså heller ikke en "implementering af OOXML i sin helhed".

hvad mener du med "Office 2007 RTM"

Huh? Mener du at du ikke kender software release cyclen? Læs gerne op her: http://en.wikipedia.org/wiki/Software_release_life_cycle#RTM Og jeg afgrænser min kommentar til det jeg selv har t

  • 0
  • 0
#90 Kristian Larsen

hvad mener du med "Office 2007 RTM"

Huh? Mener du at du ikke kender software release cyclen? Læs gerne op her: http://en.wikipedia.org/wiki/Software_release_life_cycle#RTM Og jeg afgrænser min kommentar til det jeg selv har testet og er ret specifik her idet jeg ikke har testet på alle builds og versioner og patch status'er.

Når det så er sagt, så siger vores support afdeling at compat. pack er bedre end ingenting men det virker stadig ikke godt, så perfekt er det ihvertfald ikke - afgrænsningen her er et sted mellem 1000 og 1500 brugere for os, derudover har vores support kontakt til en 5k+ andre brugere i andre sammenhænge. Så når de siger sådan, mener jeg egentlig de har noget at have det i, hvad med dig, hvor mange brugere har du supporteret som siger det fungerer perfekt?

  • 0
  • 0
#91 Jesper Lund Stocholm Blogger

Hej Carsten,

Funktionalitet kan defineres som krav. Det er den måde et stykke software specificeres på i en kontrakt. Mere luftigt er det ikke.

Problemet er ikke funktionalitetskravene som sådan - problemet er, at de ikke har rod i virkeligheden - hverken ifht konvertering eller i forhold til brugsmønstre.

Konvertering:

Isoleret set er der i dag fuld interoperabilitet imellem ODF og OOXML på de fleste af punkterne i funktionalitetsloftet - altså der er undersøttelse for "sidehoveder", "tabeller" etc i begge formater. Men i det øjeblik man begynder at kombinere tingene, så oplever vi i dag problemer med interoperabilitet. Et godt eksempel på dette er det OOXML-testdokument jeg lavede, hvor OO-klonerne crashede. Jeg har submittet en bug-report på det, og en af drengene fandt ud af, at hvis man fjernede billedet i sidehovedet, så blev dokumentet fint indlæst.

Så personen, der dannede dokumentet, kunne fint argumentere for, at "det overholder til fulde funktionalitetsloftet", men modtagerne ville alligevel opleve problemer.

Brugsmønstre:

Funktionalitetsloftet bygger på den antagelse, at brugerne kan holde sig indenfor det i deres dokumenter - men det er i mine øjne fuldstændigt urealistisk. Brugerne vil altid bruge funktionalitet, som de synes giver mening eller gør deres dokumenter "pænere" eller "kønnere". At brugerne skulle checke dokumenter imod en liste af definerede krav er ikke en ting, som jeg tror nogensinde vil ske. Derfor vil vi opleve problemer med tabelkanter, grafikanvendelser og de andre ting, som ikke er konvertérbare imellem ODF og OOXML. Det er korrekt, at man kan tage "the high road" og blot konkludere, at "så kunne de jo bare have holdt sig indenfor funktionalitetsloftet" - men det er imo en ret elitær holdning at have.

  • 0
  • 0
#92 Jakob Damkjær

Jesper, du anser dine indlæg for en succes når du har fået minus fem.

Jeg anser mine inlæg som læige i øjet når du ikke kan finde på andre modargumenter end "Du er dum fordi du bruger mere end 2 linjer på at argumentere din holdning"...

Jeg vinder, du er løbet tør for argumenter... jeg vidste jeg ville smage sejerens sødme endag hvis jeg bare blev ved med at komme med relativt gennemtænkte argumenter så ville du en dag løbe tør for krudt.

Den dag er idag.

Jeg betragter dig nu som besejret.

GO ME ! WOHOO !

Hvis du ikke har noget nyt at sige så gør os alle en tjeneste at holde op med at gøre dig selv pineligt bemærket ved at skrive kilometerlange bloginlæg uden realt indhold (du ved noget der har med virkeligheden at gøre ikke bare noget der stammer fra et microsoft FUD memo).

Jeg kan kun tilslutte mig PHKs holdning angående kvaliteten af dine indlæg.

/Jakob

PS! Doping sammenligningen er brugt til at forklare forskellen mellem positiv og negativ lister ikke dokumentformater. Den relativt klare lovgivning der blev behandlet mener jeg er god da den liste den prøver at etablere er en positiv liste og ikke en måske-negativ-liste.... Så hvis du nu næste gang prøver at forstå hvad jeg mener istedet for at gribe fat i en delproblemstilling (doping) som du tror du forstår noget om og så lade som om jeg skrev noget andet end det jeg faktisk gjorde så vil jeg måske genvinde nok respekt for dine debat manere til at vil anse dig i nærheden af at være en værdig modstander igen.

Når du så har forsøgt med det så prøv at formulere et svar som er lidt mere artikuleret end "du bruger lange ord og sætninger ergo tar du fejl" for det holder ikke helt vand du... der er et gammelt ordsprog som lyder noget i nærheden af noget med sten, glashuse og ens bolig...

Du skulle prøve at slå det op.

  • 0
  • 0
#94 Jesper Lund Stocholm Blogger

Hej Kristian,

Så Symphony som helhed er en fork ift. OOo som helhed - jeg kan af gode grunde ikke udtale mig specifikt om deres ODF implementering andet end at den toler ODF noget bedre end en OOo 1.3 :).

Helt fair - men skal vi så ikke stoppe med at snakke om Symphony - siden du ikke kan udtale dig konkret om det? Det er jo helt fair - Symphony er jo ikke OpenSource, så det er jo reelt kun IBM, der kender svarene.

Office 2007 som ift. da det blev skrevet er "Newer versions" bruger vel også stadig ECMA proposal ellers vil jeg da gerne have din dokumentation for andet.

Grunden til at jeg ikke svarede på denne del tidligere var, at jeg ikke forstod, hvad "ECMA-proposal" var - hvad er det?

Og det fungerer stadig på den måde at open er == import (ie. konvertering) og save er export == konvertering, og når nu dokumentet ER konverteret er edit vel åbenlys eller?

Joeh - men du fremhævede nu selv "læse", da du skrev:

"Nej, den giver Office XP og Office 2003 standard programmerne (dvs. excel, powerpoint og word) mulighed for at læse ECMA proposal."

Og pakken kan stadig kun bruges til Office XP og 2003 - det står iøvrigt meget tydeligt på den side, så nej Office 2000 kan ikke.

Jeg tror, at vi kigger på to forskellige sider. På http://www.microsoft.com/downloads/details.aspx?FamilyID=941b3470-3ae9-4... står der nemlig:

"By installing the Compatibility Pack in addition to Microsoft Office 2000, Office XP, or Office 2003, you will be able to open, edit, and save files using the file formats in newer versions of Word, Excel, and PowerPoint "

I så fald, eftersom den gør det samme som compat. pack [import og export af/til odf] er det altså heller ikke en "implementering af OOXML i sin helhed".

Det har du dælme ret i :o)

Og jeg afgrænser min kommentar til det jeg selv har testet og er ret specifik her idet jeg ikke har testet på alle builds og versioner og patch status'er.

Men for de ting du selv har testet - har du nogle testdokumenter vi kan se?

Når det så er sagt, så siger vores support afdeling at compat. pack er bedre end ingenting men det virker stadig ikke godt, så perfekt er det ihvertfald ikke - afgrænsningen her er et sted mellem 1000 og 1500 brugere for os, derudover har vores support kontakt til en 5k+ andre brugere i andre sammenhænge. Så når de siger sådan, mener jeg egentlig de har noget at have det i, hvad med dig, hvor mange brugere har du supporteret som siger det fungerer perfekt?

Lad os lige få noget på det rene: Microsoft Office i versioner før 2007 er IKKE implementeringer af OOXML "i sin helhed". Bla. forstår tidligere versioner af Microsoft Office ikke DrawingML, CustomXML og OMML (matematiske formler i tekstdokumenter). Jeg kunne derfor forestille mig, at de problemer I har oplevet med compat-pack skyldes netop dette - at dokumenter dannet i Microsoft Office 2007 ikke understøttes af tidligere versioner af Microsoft Office. Det er der nu ikke noget mærkeligt i.

  • 0
  • 0
#95 Jesper Lund Stocholm Blogger

Hej Michael,

Kan du da give et link til, hvor jeg kan hente kildekoden til MSO 2007, WordPerfect Office 14 eller iWorks implementation af OOXML?

Næeh - men det behøver jeg jo heller ikke. Kristian udtalte sig jo om OOXML (og ikke om kildekoden til Microsoft Office), da han sagde:

"Og eftersom den information [om legacy dokumenter] delvist er påkrævet for at kunne implementere OOXML T fuldt ud ..."

Det må jo betyde, at Kristian ligger inde med en liste over elementer eller attributter i OOXML, der ikke kan implementeres udelukkende fra spec (OOXML) men kræver viden om "de legacy dokumenter".

Den liste vil jeg gerne se.

  • 0
  • 0
#96 Carsten Sonne

Hej Jesper,

Isoleret set er der i dag fuld interoperabilitet imellem ODF og OOXML på de fleste af punkterne i funktionalitetsloftet...

Det er stadig ikke lykkedes mig at finde en beskrivelse/definition af det nævnte funktionalitetsloft. Kan du ikke sende mig et link?

Et godt eksempel på dette er det OOXML-testdokument jeg lavede, hvor OO-klonerne crashede. Jeg har submittet en bug-report på det, og en af drengene fandt ud af, at hvis man fjernede billedet i sidehovedet, så blev dokumentet fint indlæst.

Såfremt antagelse om at et billede i et sidehovede er inden for funktionsloftet er korrekt, så er konklusionen jo klar: Kravet er ikke opfyldt.

I øvrigt må det være det være de nyankommende på listens ansvar at kunne gemme korrekt i de formater der allerede findes på listen, eller i det mindste stille et værktøj til rådighed, der kan konvertere det kandiderende format til allerede godkendte standarder.

Funktionalitetsloftet bygger på den antagelse, at brugerne kan holde sig indenfor det i deres dokumenter - men det er i mine øjne fuldstændigt urealistisk.

Jeg vil mene det modsatte. Hvis man tager et kig på de dokumenter der er i omløb fra det offentlige, så består indholdet som oftest af relativ simple elementer. Det er jo ikke anderledes end HTML 4.01 er en standard der favner så bredt at almene hjemmesider kan vise deres indhold udelukkende via HTML 4.01.

Brugerne vil altid bruge funktionalitet, som de synes giver mening eller gør deres dokumenter "pænere" eller "kønnere". At brugerne skulle checke dokumenter imod en liste af definerede krav er ikke en ting, som jeg tror nogensinde vil ske.

Office 2007 har en ganske glimmerende kompatibilitetsfunktion når der gemmes i andre formater end docx, xslx, pptx, etc. Her kommer en advarsel om at du benytter elementer der ikke er understøttet af det nyeste format og du vil miste informationer. Hvis du alligevel gemmer, vil de nye elementer blive konverteret til elementer som er en del af den gamle standard. Det fungere da fint.

Det er korrekt, at man kan tage "the high road" og blot konkludere, at "så kunne de jo bare have holdt sig indenfor funktionalitetsloftet" - men det er imo en ret elitær holdning at have.

Jeg vil mene det stik modsatte. Det er et spørgsmål om at holde målet for øje og være lidt pragmatisk.

Hvis du prøver at taget de objektive briller på og kigger på hele diskussionen, så vil du ret hurtigt indse at det er alle mulige andre agendaer der styre dagsordnen.

Der er meget få, der er interesseret i at holde fokus på den egentlig opgave og en løsning der tilgodeser de faktiske behov. I stedet bruges emnet til at fremme helt andre interesser.

Mvh Carsten

  • 0
  • 0
#97 Jesper Lund Stocholm Blogger

Hej Carsten,

Det er stadig ikke lykkedes mig at finde en beskrivelse/definition af det nævnte funktionalitetsloft. Kan du ikke sende mig et link?

Jeg prøvede selv forgæves på ITST.dk den anden dag, men en anden var i en diskussion herinde for et par uger siden så venlig at henvise til denne rapport:

http://www.konkurrencestyrelsen.dk/fileadmin/webmasterfiles/publikatione...

Såfremt antagelse om at et billede i et sidehovede er inden for funktionsloftet er korrekt, så er konklusionen jo klar: Kravet er ikke opfyldt.

Nemlig - men det detalje niveau beskriver funktionalitetsloftet ikke, og derfor er nytten af det meget begrænset.

Da vi i CIBER i sin tid deltog i den tekniske udredning af ITSTs pilotprojekter så vi nøjagtig den samme opførsel; nemlig at et dokument punkt for punkt var indenfor loftet - men en nummereret liste i et sidehoved med et billede i forsvandt.

Jeg er ikke som sådan imod et funktionalitetsloft - men det skal konkretiseres meget mere end det er i dag for at være rigtigt nyttigt.

I øvrigt må det være det være de nyankommende på listens ansvar at kunne gemme korrekt i de formater der allerede findes på listen

Ja, det er jeg så uenig med dig i :o)

Jeg vil mene det modsatte. Hvis man tager et kig på de dokumenter der er i omløb fra det offentlige, så består indholdet som oftest af relativ simple elementer. Det er jo ikke anderledes end HTML 4.01 er en standard der favner så bredt at almene hjemmesider kan vise deres indhold udelukkende via HTML 4.01

Det er muligt,at det er din erfaring - min er en anden. Jeg har faktisk udelukkende arbejdet for offentlige instanser/styrelser/selskaber, og en stor del af de dokumenter, der kommer forbi min indbakke kan bestemt ikke beskrives med BBCode (for nu at sige det lidt populært).

Office 2007 har en ganske glimmerende kompatibilitetsfunktion når der gemmes i andre formater end docx, xslx, pptx, etc. Her kommer en advarsel om at du benytter elementer der ikke er understøttet af det nyeste format og du vil miste informationer. Hvis du alligevel gemmer, vil de nye elementer blive konverteret til elementer som er en del af den gamle standard. Det fungere da fint.

Ja, sådan en har OOo også. Jeg stiller mig blot tvivlende over for, om brugerne rent faktisk bruger den funktion.

(med mindre man naturligvis pisker dem til det, og det kan man jo vælge at gøre)

:o)

  • 0
  • 0
#98 Kristian Larsen

Jesper denne passus:

"By installing the Compatibility Pack in addition to Microsoft Office 2000, Office XP, or Office 2003, you will be able to open, edit, and save files using the file formats in newer versions of Word, Excel, and PowerPoint" Den henviser vel til formaterne? Så ja, Office 2003 kan i RTM udgaven, uden compat. pack også læse Office 2000's doc format. Officielt kan den vidst også læse Office 97's udgave, selvom field reviews siger at det ikke skulle være helt optimalt.

Men for de ting du selv har testet - har du nogle testdokumenter vi kan se?"

Nej, det var interne arbejdsdokumenter jeg ikke kan dele.

Microsoft Office i versioner før 2007 er IKKE implementeringer af OOXML "i sin helhed".

Ok, men så er det jo også forkert når du skriver at 90% af alle Office brugere kan bruge formatet.

Og hvis vi dertil lægger:

Ja, sådan en har OOo også. Jeg stiller mig blot tvivlende over for, om brugerne rent faktisk bruger den (insert: kompatibilitets-) funktion.

Så er det vel et moot point, idet vi så er tilbage til, hvor mange bruger Office 2007.

  • 0
  • 0
#99 Kristian Larsen

Helt fair - men skal vi så ikke stoppe med at snakke om Symphony - siden du ikke kan udtale dig konkret om det? Det er jo helt fair - Symphony er jo ikke OpenSource, så det er jo reelt kun IBM, der kender svarene.

Du har selv med din egen test konstateret at OOo og Symphony ikke bruger samme ODF parser og givet symphony et "rødt" lys. Men du bliver alligevel ved med at påstå at det er samme implementering som SUN's, hvordan hænger det sammen?

Og det ændrer iøvrigt ikke på at pakken som helhed er en fork af OOo og dermed en uafhængig implementation præcis som AIX er uafhængig af HP-UX.

  • 0
  • 0
#100 Carsten Sonne

Nemlig - men det detalje niveau beskriver funktionalitetsloftet ikke, og derfor er nytten af det meget begrænset.

Loftet i rapporten er ubrugeligt. Hvis det var krav i en kravspecifikation, ville det være det samme som at give kunden en blanco check hvor han kunne kræve mere og mere med henvisning til kravspecifikationen.

Krav skal selvfølgelige være konkrete og målbare.

I øvrigt er OLE objekter beskrevet i dokumentet. Det er Windows teknologi, der ikke lader sig forene med en åben standard. Herved diskvalificere listen sig selv ift. konklusionspapiret.

"I øvrigt må det være det være de nyankommende på listens ansvar at kunne gemme korrekt i de formater der allerede findes på listen"

Ja, det er jeg så uenig med dig i :o)

Hvis man ikke laver den antagelse, vil konstruktionen ikke fungere.

Hvis der findes 2 standerder på listen og en 3 skal optages, så skal den 3 jo kunne konverteres til de 2 andre for at opfylde kravet om interoperabilitet.

Da de 2 andre allerede findes på listen, må det nødvendigvis være et krav at den 3. standard stiller værktøjer til rådighed der kan konverterer til 1 og 2. Det kan ikke være 1 og 2's ansvar at 3 nu skal med på listen. 1 og 2 er allerede godkendt.

I modsatte fald, risikere man at 1 og 2 har delvis support for 3, men alligevel ikke. Lidt som du beskriver i dit eksempel. Resultatet er at interoperabilitet forsvinder og succeskritirierne er ikke længere opfyldt.

Det er muligt,at det er din erfaring - min er en anden. Jeg har faktisk udelukkende arbejdet for offentlige instanser/styrelser/selskaber, og en stor del af de dokumenter, der kommer forbi min indbakke kan bestemt ikke beskrives med BBCode (for nu at sige det lidt populært).

Ok, lad os se bort fra mine erfaringer og forholde os nøgtern til problemstillingen. Ideen i et funktionalitetsloft er at ramme de almene behov. Det er gjort før med mange andre standarder, f.eks. HTML.

Den eneste forskel her, er at der ikke er noget alternativ. Derfor er det måske lidt mere indlysende at blikkende tekst i 3D der kan roterer ikke er et alment behov.

Ja, sådan en har OOo også. Jeg stiller mig blot tvivlende over for, om brugerne rent faktisk bruger den funktion.

(med mindre man naturligvis pisker dem til det, og det kan man jo vælge at gøre)

Ja præcis. Det bliver borgeren tvunget til hvis han vil udvkesle dokumenter med andre inden for funktionalitetsloftet, herunder staten. Det er ikke anderledes end hvis jeg vil udveksle dokumenter fra Word 2007 med en kunde der 'kun' har Word 2003, så må jeg gøre det samme.

Hvis systemet skal fungere, skal der være nogle klare regler som skal overholdes. Det er det vores samfund bygger på. Hvis man kan få en lokalplan til at virke og tvinge borgerne til at deres tag skal være røde lertegl, så kan man vel også få dem til at gemme i et bestemt format når de sender dokumenter.

  • 0
  • 0
#101 Jesper Lund Stocholm Blogger

Hej Kristian,

Du har selv med din egen test konstateret at OOo og Symphony ikke bruger samme ODF parser og givet symphony et "rødt" lys. Men du bliver alligevel ved med at påstå at det er samme implementering som SUN's, hvordan hænger det sammen?

Det har jeg faktisk ikke konkluderet i testen. Jeg har blot konstateret, at et ODF 1.0-dokument dannet af OOo 2.4 indlæst i Symphony 1.3 taber information.

Jeg mener bestemt ikke, at man kan konkludere, at Symphony og OOo ikke bruger samme ODF-parser.

Men du bliver alligevel ved med at påstå at det er samme implementering som SUN's, hvordan hænger det sammen?

Jeg tvivler sådan set ikke på, at IBM har lavet rettelser til den OOo-kildekode de har baseret deres Eclipse-brugerflade på, Men det ændrer jo ikke på, at den er baseret på kildekode fra Sun og derfor i et eller andet omfang afhængig af denne.

Og det ændrer iøvrigt ikke på at pakken som helhed er en fork af OOo og dermed en uafhængig implementation præcis som AIX er uafhængig af HP-UX.

Jeg forstår ikke helt dette argument. Eksempelvis kunne jeg forestille mig, at Office 2007 er en fork af kildekoden til Office 2003 i Microsofts eget repo - ganske som Office 2003 er det ifht Office XP. Det synes jeg dog ikke giver anledning til at konkludere, at kildkoden til Microsoft Office 2003 og kildekoden til Microsoft Office 2007 er "uafhængige".

Jeg fandt dog noget fra hestens egen mund omkring kobling imellem Symphony og OOo:

http://www-03.ibm.com/press/us/en/pressrelease/25912.wss

Der står helt konkret:

"IBM Lotus Symphony is based on OpenOffice code, with IBM enhancements that allow new capabilities through Eclipse plug-ins and incorporate some of the OpenOffice 3.0 code."

og

"Karasick also pointed forward to the Symphony roadmap for 2009, when [b]future generations of Symphony will be developed entirely on the ODF 1.2 and OpenOffice 3.0 software code base, bringing it in line with the newest OO technology.[/b] This advance will also enable seamless interoperability with Microsoft Office 2007 file formats and support Visual Basic macros next year. IBM plans to deliver more than 60 new features to Symphony in 2009, building it into a versatile tool for work while pledging to keep it free on the Web for all. [b]By synchronizing Symphony's user interface with the underlying OpenOffice 3.0 code base, IBM expects the upcoming wave of planned contributions to make a significant impact to the OpenOffice developer community[/b] and its users throughout 2009 and beyond."

(min fremhævning)

Dette siger mig, at kildekoden fra Suns OOo er en central del af Symphony samt at det primære i IBMs udvikling har været på brugerfladesiden.

Derfor giver det for mig ikke mening at tale om Symphony som en uafhængig ODF-implementering, da ODF-implementeringen tydeligvist er lavet af Sun.

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