Hvad er bedst - en eller to standarder?

En, selvfølgelig! Præcis det kan man se Jesper Laisen svare [Opdateret: 16/05 - http://www.version2.dk/artikel/1788] og med god grund ' hvorfor vedligeholde to standarder? Implementering og udrulning bliver bare dobbelt så besværligt!

Jeg tror at mange har sympati med tanken om en og kun en standard. I den aktuelle ODF/OpenXML debat er opfattelsen at designmål, forretningsområde, brug og funktionalitet for de to formater er identiske og at vi med fordel kan udelukke en af de to standarder.

Hvad nu hvis Version2 igen spørger Jesper om han vil have en eller to standarder og istedet for ODF/OpenXML siger ISO/IEC IS 15444-1 og ISO/IEC 15948 (hhv JPG og PNG)  - begge standarder er til grafik ? typisk brugt til billeder. Jeg ved ikke hvad Jesper vil svare, men JPG og PNG har store fællesnævnere, men samtidig er der også steder hvor de er forskellige, hvilket berettiger til, at der er to standarder og at de sameksisterer!

Hvis vi følger samme logik som vi pt har i ODF/OpenXML diskussionen, kommer vi ud i en situation hvor der for hvert 'område' skal vælges en og kun en standard/teknologi. Det betyder at vi giver embedsmændene en umulig opgave og vi beder politikerne om at detailstyre området. Hvis jeg løber linen helt ud med den logik, så gælder det for B103 standardkataloget, at der er/vil komme mange 'dubletter'.

Jeg starter en liste her og andre er velkomne til at fylde mere på  - SSL/TLS vs. WS-Security, HTML vs. XHTML, PNG vs. JPG, WS-Eventing vs. WS-Notification, WS-Reliabillity vs. WS-ReliableExchange, 802.11x vs. Bluetooth, C vs. C# osv. ... 

Det haster med den liste ' hvis politikerne skal tage stilling til alle disse konflikter inden 1. Januar 2008....og ja, jeg synes også at det er en absurd øvelse, men er det ikke det logiske efterspil ved en diskvalificering af enten ODF eller OpenXML' 

René Løhdes billede
René Løhde er IT Arkitekt og "Chief Know-It-All" hos Crayon A/S. Han har arbejdet som IT-arkitekt og cloud computing løsningsspecialist hos Microsoft. Før det, var han blandt andet ansat i IT- og Telestyrelsen, som udvikler og konsulent.

Kommentarer (120)

Finn Sørensen

Det er så en sammenligning jeg ikke helt synes holder - med næsten ethvert grafisk visningsprogram/redigeringsprogram kan man konvertere imellem de 2 billedformater. Det er betydeligt sværere mellem de 2 nævnte dokumentformater. Især den ene vej, da det indeholder proprietær kode.

Min enkle mening til spørgsmålet er at vedtage ODF som den ene, generelle standard, og så lade det være op til leverandørerne - især, naturligvis, MS - at komme efter konverteringsværktøjerne begge veje OG evt. gøre kildekoden til disse åbne for alle, så det kan udnyttes fuldt ud. Med seneste udmelding om patenter i Open Source der bryder med MS' licenser synes vi dog på vej tilbage til den sorte skole... fra et datateknisk synspunkt, tager jeg helt fejl?

Jacob Bang

Siden du virker så klog på det område ville jeg da gerne hører din forklaring på de forskelle i ODF og OOXML der gør at der er nød til at være begge to. Hvad er det som OOXML kan som ODF ikke kan og omvendt?

Jeg kan ikke se nogen forskel men den er der sikkert. Dog kan jeg se en forskel i PNG vs. JPG men mener at man sagtens kunne leve med kun PNG da det format gør opgaven ganske glimrende.

Christian Dias Løgberg

Som du jo fint viser, er der mange områder, hvor det er gavnligt med flere standarder. Dokumentområdet kan også være en af dem, men det kræver at standarderne kan noget forskelligt. Som f.eks. ren tekst og HTML der hver især har styrker og svagheder og derfor kan berettiges i forskellige sammenhænge.
Det ville også kunne gælde for ODF/OOXML. Sålænge alle kontorpakker kan åbne og gemme i begge formater er alt i skønneste orden.

Problemet med OOXML er bare stadig, at standarden ikke er åben nok til at andre end Microsoft kan implementere den. Og nu vi har en MS-"evangelist" ved hånden: Hvad er overhovedet grunden til at man bibeholder levn fra tidliger Word-formater i stedet for at rette formateringen op i konverteringen fra .doc til OOXML?

Mikkel Høgh

PNG og JPG (JPEG, faktisk) er to helt forskellige måder at komprimere billeder på, hhv. lossless og lossy komprimeringer med vidt forskellige formål og implementeringer. JPEG er, kort fortalt, rettet mod fotografi - det ligger lidt i navnet JPEG. Det er godt til at gemme "organiske" billeder - altså billeder hvor der ikke er store ens farveflader, gentagende mønstre osv. Dens komprimering er dermed ret dårlig til computergenereret grafik.

PNG er derimod rettet mod grafik. Det understøtter i modsætning til JPEG alpha-transperens og den komprimering der bruges er optimeret til computergenereret grafik.

TLS/SSL sammenligningen holder efter min mening heller ikke helt. For at citere Wikipedia: "There are slight differences between SSL 3.0 and TLS 1.0, but the protocol remains substantially the same." TLS er altså nærmest SSL 4.0.

Ligesådan med XHTML som er en videreudvikling af HTML. Et forsøg på at overføre HTML til SGMLs efterfølger, XML.

802.11x og Bluetooth har så vidt jeg ved også vidt forskellige formål.

C og C# kan også dårligt siges at være sammenlignelige på den måde du antyder. C er trinnet over assembly, mens C# er et objektorienteret sprog der håndterer alt det sure arbejde med malloc og den slags for en - en videreudvikling af Java - og C# er vist i øvrigt aldrig blevet ISO godkendt.

OOXML og ODF er derimod begge komprimeret-XML-baserede dokumentformater som begge (officielt) er designet til at fremme interoperabilitet, og på trods af at specifikationen for OOXML efter sigende er på 6000 sider, så har jeg endnu ikke hørt hvad det er det kan til forskel fra ODF (hvis specifikation "kun" er på 738 sider), måske lige ud over at sikre Microsofts forsatte dominans på markedet for kontor-software.

De andre standarder kender jeg ikke, men jeg synes din sammenligning virker lidt søgt.

Georg Sluyterman

Det jeg umiddelbart bemærkede ved debatten mellem John Gøtze og René Løhde, som Version2 og Prosa havde arrangeret for ca. 3 uger siden var, at de features som René synes var mægtigt smart ved, den ikke åbne standard, EOOXML, ville blive implementeret i ODF v. 1.2.

Hvis der derudover mangler noget som ODF bare /må/ have, så tror jeg bestemt det er realistisk at den danske stat ved medlemsskab af OASIS kan få det implementeret i en fremtidig version..

Jacob Volstrup

Nu skal man jo også lige bide mærke i at de fleste af de nævnte standarder ikke er kommet på samme tid (jeg kender ikke til dem alle, så jeg tager sikkert fejl omkring enkelte).

Hermed mener jeg at JPEG kom langt tidligere end PNG, og PNG standarden blev skabt fordi man havde opdaget nogle mangler med JPEG (og andre billedformater) som ikke umiddelbart lod sig blive implementeret i disse. Dermed kan man se på det som en evolutionær proces (hvilket jo også gælder for SSL/TLS) hvilket er ganske naturligt indenfor alle områder - ikke bare IT. Derfor ser jeg personligt en stor fejltagelse i at man vil komme med to dokumentstandarder som kan stort set det samme på det samme tidspunkt. Der er derfor intet ved den evolutionære tilgang som skulle tale for at der komme to standarder for det samme på samme tid.

Hvis begge standarder/projekter var open source kunne man godt regne med at de hurtigt ville finde sammen og forene kræfterne fremfor at begge lejre skulle ordne det samme - det er set og sket mange gange før. I dette tilfælde vil vi dog ikke se noget sådanne ske da Microsoft med garanti vil holde de sidste kort tæt til kroppen.

Det skal slutteligt siges at jeg ikke nødvendigvis er open source evangelist, men i sager hvor det drejer sig om dokumenter til slutbrugeren (om det så er den danske stat eller Hr. Jensen i Sdr. Omme) mener jeg det er vigtigt at man på ingen måde binder sig til ét bestemt produkt.

Simon Grønnegaard

Jeg havde endelig glædet mig til lidt modspil i diskussionen om valg af åben standard. Det er vel kun fair at vi hører synspunkter fra begge sider. Derfor kan jeg ikke forstå at du springer over hvor gærdet er lavest og stiller spørgsmålstegn ved om vi overhovedet bør vælge, hvis begge er lige gode?

Dine sammenligninger kan, som det er påpeget tidligere i diskussionen, ikke sidestilles med den nuværende debat. Hvorfor skulle valget være et ECMA godkendt OOXML format i mod et åbent ISO godkendt ODF format? Vi er jo enige om der kun skal være et.

-Simon

PS: link til artikel om Jesper Laisen: http://www.version2.dk/artikel/1788?highlight=jesper+laisen

PPS: Et "velkommen til" skal også lyder herfra

Poul-Henning Kamp

Dit eksempel med JPEG og PNG halter gevaldigt for du glemte TIFF (eller også har du aldrig hørt om det ?)

Den "rigtige" image standard hedder TIFF og den er mange gange bedre end JPEG og PNG for det er en "container" standard der kan udviddes hver gang vi kommer på en bedre ide.

Derfor bruger den grafiske branche TIFF, der er nemlig plads til kaliberingskurver, pantone specifikationer, underfarvereduktionslag osv.

Men fordi dem der "ejer" den standard blev opfattet som nogle kontrære og pernittengrynede bæster, deres version hedder at de ville have lov til at gøre det ordentligt, så var der andre der kastede JPEG sammen, uden at læse alt det med småt.

Om JPEG kunne man derfor ikke få en klar melding på hvorledes det forholdt sig med rettigheder og derfor lavede en tredje gruppe så PNG.

Når man tager dette forløb i betragtning, så får man et skoleeksempel på hvorfor vi skal have ODF og kun ODF:

Balladen med standarder starter når nogle kaster en standard sammen, bare for at kunne kalde det en standard.

En god standard er gennemført og veldefineret, den har ingen løse ender.

For at nå dette niveau af kvalitet, så kan standarden ikke være større end folk kan læse den, fra ende til anden.

Derfor partitionerer man i stort omfang standarder, så man får noget overskueligt.

F.eks importerer TIFF formatet CCITT's fax komprimeringer og enkodninger, istedet for at finde på nogen selv.

Du kan nu selv begynde at tælle hvor mange penalties OOXML får:

Løse ender ? Det må man da kalde alle de der "legacy" ting og underlige bitmaps.

Gennemarbejdet ? Ikke når den fylder 6000 sider og der kun gives få måneder til review.

Konsistent ? Højst usandsynligt, se ovenfor.

Partitioneret ? Nej, der defineres nye underlige formater hvor der existerer glimrende standarder man kunne bygge på.

ODF klarer sig bedre på alle disse punkter (men jeg siger ikke at ODF er perfekt!).

Et perfekt eksempel på balladen ved at have to standarder kan du se nede ved dit fodpanel:

I Danmark har vi i mange år haft vores egen standard for stikkontakter, den bruges ingen andre steder i verden.

Nu vil man tillade anvendelse af den franske standard også, for at få billigere elmateriel på markedet.

Det betyder at man skal installere HPFI i alle elinstallationer, fordi ellers bliver der et sikkerhedsmæssigt hul når materiel fra de to standarder blandes.

Vi skal have en standard og kun en, og af de to der er på bordet er ODF den bedste.

Poul-Henning

Jesper Krogh

Hej Rene.

Jeg syntes du glemmer den væsentlige pointe at MS-OOXML slet ikke lever op til den definition af åben standard der er vedtaget i B103.
http://www.ft.dk/Samling/20051/beslutningsforslag/B103/som_fremsat.htm

Se evt. pto's gennemgang: http://www.version2.dk/artikel/2430

Dertil kommer at, hvis du læser B103, så er en klar hensigt med lovforslaget at få øget konkurrence på markedet. Har vi nogen som helst grund til at tro at det bliver tilfældet ved at benytte MS-OOXML som Microsoft blot kan trykke en ++ version af når de har lyst og rulle en ny kontorpakke ud med forspring for alle andre på markedet. Bemærk at Microsofts garantier om at kunne implementere den, kun gælder nuværende version af standarden, igen garantier for kommende versioner.

Jesper, SSLUG

Jon Friis

Hej Rene - og velkommen i krudttønden.

Jeg mener ikke der er noget galt med to forskellige standarder - hvis altså der er et behov !

Men lad dog for guds skyld den dansk regering vedtage at det offentlige danmark bruger en og kun en standard og lad det så i sammen omgang være den bedste, nemlig ODF.

Mvh
Jon Friis

Jakob Røjel

Dette er vel et klassisk eksempel på hvorfor IT projekter fejler, dette er en rigtig teknikker diskussion, sådan lidt som at diskutere acceleration og topfart mellem en Ferrari og en Fiat Punto hvis opgaven er at køre op af motorring 3 i myldretiden.

Jeg synes det kunne være rart at få belyst nogle forretningsmæssige vinkler før vi graver og ned i beslutninger som en standard er bedre end to, den standard der kom først er bedst, en standard fra Microsoft er ikke en rigtig standard.

Så det kunne være rart hvis nogle af de der blev berørt (andet end på de filosofiske plan), nemlig offentlige IT chefer/arkitekter kunne give noget indspark til spørgsmål som

  • Hvilket problem vil et dokumentformat løse. Problemet med to standarder findes jo kun hvis man vil udveksle editbare dokumenter mellem organisationer. Der er vel ikke nogen der i 2007 tror at dataudveksling eller udfyldelse af formularer foregår bedst i Word/OpenOffice.
  • Hvis nu man besluttede sig for ODF som eneste dokument standard, hvad vil man så rent praktisk gøre. Konvertere alle sine dokumenter til ODF eller bibeholde Word og konvertere eksterne dokumenter til ODF, måske forklare hvorfor man ikke lige kan implementere ODF.
  • Er dokument formater virkelig på top 10 over udfordringer med åbne standarder og interoperabilitet i det offentlige. Jeg tror at der er større problemer med de fleste systemer/systemleverandører eller databaser for at nævne noget.

Mvh. Jakob

Peter Mogensen

Hej Rene,
Jeg ved ikke om jeg er helt enig i alle dine analogier, men det er også ligemeget. Du har fremstillet dit argument meget klart med PNG/JPEG eksemplet. To forskellige formater, to forskellige formål. I sådanne tilfælde er det selvfølgelig meget fornuftigt at have to forskellige standarder.

Jeg går ud fra at du er enig i at de ikke begge "bare" er grafik-formater, men at JPEG er beregnet til "billeder" - d.v.s. egentlig fotografiske optagelser og PNG er beregnet til (som navnet siger) "Netværks grafik" - d.v.s. bitmapped pixeleret grafik (inkl. alpha-channel).

Så når nu det er slået fast, så går jeg ud fra at dit argument er at ODF og EOOXML også er to forskellige formater med forskellige formål.

ODF er jo et format beregnet til udveksling af "office" arbejdsdokumenter gnidningsløst mellem applikationer fra forskellige leverandører.
Det kunne være interessant at høre, hvis EOOXML så ikke også er det, hvad du så mener det er?

Jesper Lund Stocholm

Definitionen af åbne standarder som beskrevet af Peter Toft ser faktisk glimrende ud - problemet med den er - som jeg ser det - at den er for snæver. Den skaber et godt grundlag som anbefaling for et konkret valg, men hvis den skal opfattes som en definitiv liste, der ikke må afviges fra, så kommer den let til at virke kontra-produktivt. Hvis man dertil udelukkende fokuserer på at en standard opfylder kravene, så kan man nemt komme til at designe standarden, så den opfylder kravene - i stedet for at designe en god standard.

Pkt. 1:
ODF dækker så vidt jeg kan se dette punkt, men er det nok, når ODF kan indeholde applikationsspecifikke udvidelser, der ligger udenfor specifikationen? ODF er sikkert veldokumenteret og den fulde specifikation er offentlig tilgængelig. Men er det nok, når den fulde specifikation ikke indeholder specifikation om noget så centralt som beskrivelse af formler? Anken imod MS Office er her alene, at den indeholder en liste af referencer til tidligere versioner af MS Office-applikationerne. Det er for såvidt træls nok - men jeg mener virkeligt ikke, at det er værre. Når nu formatkampen er ovre, så skal vi (og her mener jeg konkret bla. jeg selv) jo til at arbejde med formaterne og skrive parsere, konverteringsrutiner og lignende. Hvad vil I have, at jeg stille op med et regneark-ODF-dokument, hvor jeg ikke kan være sikker på, hvordan formler er dannet?

Pkt2:
I definitionen står der bla. : "Frit implementerbar uden økonomiske, politiske eller juridiske begrænsninger på implementation og anvendelse."

Her nævnes ofte som kritik af OOXML, at Microsoft ejer nogle patenter, som skulle (jeg er ikke klar over hvilke) dække over dele af OOXML. Microsoft har lovet ikke at håndhæve disse patenter overfor andre implementeringer. Peter Toft bemærker her, at det er usikkert, om ikke-håndhævningen dækker legacy-attributterne (FUD?). Lad mig her gøre opmærksom på, at ODF også er dækket af patenter - bla. ejet af Sun. I deres fraskrivelse af håndhævning af patentet står der:

"Sun irrevocably covenants that, subject solely to the reciprocity requirement described below, it will not seek to enforce any of its enforceable U.S. or foreign patents against any implementation of the Open Document Format for Office Applications (OpenDocument) v1.0 Specification, or of any subsequent version thereof ("OpenDocument Implementation") in which development Sun participates to the point of incurring an obligation, as defined by the rules of OASIS, to grant (or commit to grant) patent licenses or make equivalent non-assertion covenants."

Hvis der skal fluekneppes som med OOXML-formatet, så læg mærke til ordene "any implementation of the Open Document Format [..] in which development Sun participates". Skulle Sun droppe arbejdet med ODF, er der altså ingen garanti for, at de ikke vil håndhæve deres patenter.

[frustration over debatten, bær over med mig :o) ]
Uanset hvordan I vender og drejer det, så er ODF bestemt ikke et perfekt format (ellers ville man vel ikke have nyere versioner i pipe-line), og det ville klæde jer ODF-fortalere at forholde jer konstruktivt og kritisk til dette i stedet for udelukkende at rette jeres kritik af OOXML (og Microsoft). Der lyder meget brok over, at politikerne ikke lytter nok til jer, men når I fremstår så "religiøse" i jeres udtalelser, så kan jeg sgu ikke bebrejde dem det. I fremstiller ofte sagen som sort/hvid, når den snarere er "vammel-grå", hvis man tager flere parametre ind i sammenligningen end sideantal. Peter, jeg synes din gennemgang af OOXML ifht definitionen af en åben standard er god, og jeg er enig i de kritikpunkter du fremkommer med om OOXML. Det ville dog have klædt dig at vride ODF igennem samme maskine som OOXML. Du ville dermed have bidraget til at gøre debatten mere kvalificeret - i stedet for blot at bidrage til "ODF-ernes" mudderkastning. Din artikel bliver jo nu pludselig brugt som "sandhedsvidne" i diskussionen, når den bestemt ikke er det - den er derimod et softwarepolitisk partsindlæg.

Jesper Krogh

Hej Jesper Lund Stockholm.

Du skriver:
"Hvis man dertil udelukkende fokuserer på at en standard opfylder kravene, så kan man nemt komme til at designe standarden, så den opfylder kravene - i stedet for at designe en god standard."

ODF er designet til at være et åbent dokumentformat til udveksling af dokumenter mellem flere applikationer. I øjeblikket er den implementeret (eller påbegyndt) i en hel del programmer:
http://en.wikipedia.org/wiki/OpenDocument_software#Word_processors

MS-OOXMl er SVJV designet til at være kompatibelt med tidligere versioner af Microsoft Office's dokumentformat. Og det eneste der skulle gøre at denne parameter er noget der er værd at tage i betragtning er at der er en hoben af dokumenter i forvejen.

Mener du at MS-OOXML lever op til kravene og intentionerne bag B103?

Jesper

Jesper Lund Stocholm

Dette er lige præcist så symptomatisk for diskussionerne med "jer", at jeg bruger tid og energi på at undersøge og påpege nogle konkrete problemstillinger i diskussionen - og du ænser dem overhovedet ikke. I stedet tager du en snip ud af sammenhæng og kommenterer på den i stedet. I min familie er vi ret diskussionslystne, men der er nogle familiemedlemmer, hvor det er helt tydeligt, at de i en diskussion ikke lytter til andres argumenter - men derimod blot sidder og venter på, at de andre holder pause, så de kan sige noget selv. Præcist samme følelse får jeg, når du svarer som du gør her. For nu at sige det på godt jysk, så er det røv-træls.

Men måske skal jeg tage din manglende kommentering på resten af mit indlæg som indtægt for, at du er enig med mig? Den, der tier, samtykker jo ... :o)

PS: Det hurtige - omend noget nuanceforladte - svar på dit spørgsmål er 'ja'.

PPS: Jeg mener ikke, at bagudkompatibilitet er et godt argument /for/ OOXML.

Peter Juhl Christiansen

For at sige det som det er forstår jeg ikke helt denne OOXML vs ODF diskution.

koger man kravet til en dokument standart i det offentlige ned, er der som jeg ser det et "teoretisk" og et pratisk krav:

-Det teoretisker er at det skal være en standart, udfra vedtagede definoioner og godkendt som sådan.

-Det prakiske: Der skal findes flere produkter til visning og editering, gerne også gratis produkter således at envher borger uden at blive pålagt en ekstra udgift kan sende og modtage dokumenter til/fra det offentlige.

Opfylder OOXML disse krav NEJ, kan det tænkes at det kommer til det, ja det kan det vel, men intil da er det for mig at se IKKE relevant at tage det i betragtning.

Opfylder ODF disse krav JA!! altså er der kun et format at vælge mellem.

Det er af precist den grund at både Belgien og Norge har sagt, i første omgang er det ODF, og så kan vi snakke om OOXML senerer. Og det er precsit det Danmark også bør gøre!!

Dog vil jeg tilføje at jeg bestemt mener at man internt i en organitaion kun bør arbejde med et format, at man så evt vælger at sige OK, man må godt sende et gammeldag papir brev, en PDF, ODF eller OOXML. Da det, hvis det ellers er en åben standart, smeret frit kan konverteres til det format man internt har valgt.

Kristian Larsen

Jeg ser personligt en konsensus om følgende:
1. Et format ville være bedst.
2. ODF ville være bedst at vælge hvis man kun skal vælge 1 format.
3. MEN vi skal have bagudkompatibilitet og bør derfor overveje EOOXML.

Det er udfra at have læst høringssvar, diskussioner og andet.

Min anke i denne sammenhæng er:
Et delformål med den åbne standard inden for det offentlige må være at sikre adgang til dokumenterne fremover.
Hvis dette skal sikres ift. EOOXML må det være nødvendigt at konvertere gamle dokumenter til EOOXML OG sikre sig at den KUN bruger de dokumenterede dele af standarden.
Eftersom den eneste tilgængelige implementation på markedet ikke tillader at sikre dette maskinelt, og det derfor skal gøres manuelt vil det arbejde have uoverskuelige dimensioner.

Og derfor konkluderer jeg at punkt 3. rent faktisk taler imod EOOXML og de 2 første punkter taler for sig selv.

Jesper Lund Stocholm

> Et perfekt eksempel på balladen ved at have to
> standarder kan du se nede ved dit fodpanel:
>
> I Danmark har vi i mange år haft vores egen
> standard for stikkontakter, den bruges ingen andre
> steder i verden.

Eksemplet med stikkontakter er for simplificerende, men skal jeg blive i eksemlet kunne man jo argumentere for følgende: I den danske standard for stikkontakter er der to typer stik:

  • Stik uden jord
  • Stik med jord

Han-stikkene uden jording kan bruges i stikkontakter med jording, og han-stikkene med jording kan med en adapter bruges i hun-stik uden jording. Stikkene uden jording ordner de fleste opgaver uden problemer - nemlig at give strøm til apparater. Har man derimod specifikke behov for at ens dims skal jordes, så anvender man derimod et jordstik.

Pointen i ovenstående er, at begge typer stikkontakter udefra betragtet blot er "stikkontakter". Der er endda overlap imellem anvendelsesområderne, men den ene kan noget, som den anden ikke kan - og hvis man har specifikke behov for jording, så anvender man blot et jordstik.

Dén fleksibilitet ønsker jeg at have ved vedtagelse af to formater.

PS: Én af mine lærdomme ved alt for meget tid brugt på usenet er, at man skal afholde sig fra analogier, da de sjældent belyser mere end de forvirrer. Skal man dog bruge en analogi, så bør man finde en analogi i bilverdenen :o) .

Jørgen Ramskov

Du har helt ret i at det kan være relevant at foretage et valg for andre ting end lige dokumentstandarder, men det er vel ikke alle steder at det er relevant. Umiddelbart vil jeg godt så tvivl om det er relevant i forbindelse med f.eks. "C vs. C#"?

Microsoft har gentagende gange sagt at der er ting ODF mangler som OOXML har, men det kan jeg ærligt talt ikke tage seriøst. Microsoft har haft lige så mange muligheder for at hjælpe til med at standardisere ODF (langt bedre muligheder end andre har haft i forbindelse med OOXML) så de mangler Microsoft mener gør ODF ubrugelig for dem, det er udelukkende deres egen skyld. De har selv valgt ikke at deltage i standardiserings arbejdet af ODF.

Jesper Lund Stocholm: Jeg tror årsagen er at mange simpelthen er træt af MS. MS er en bølle af format - det er der utallige eksempler på.
Se f.eks. hvad der skete i Massachussets - de gik så vidt som at smæde personer til hvilket endte med at vedkommende kvittede sit job.
I den seneste rapport fra "the Olliance Group" som MS er hovedsponsor for står der bl.a.:

"Open source lacks compliance with many standards when compared with proprietary solutions. These standards include universal standards such as ISO, and industry-specific standards (financial industry standards, health care industry standards, etc.). It was acknowledged however, that open source offers some advantages in the area of technology standards through its openness and transparency and its ability to facilitate the creation of de facto standards such as Eclipse and ODF."

Det er jo direkte løgn!

Det seneste eksempel er så at MS nu igen påstår at bl.a. Linux krænker en række af deres patenter og de siger endda hvor mange de drejer sig om, men vil de fortælle hvilke? Nej, det vil de selvfølgeligt ikke for det er selvfølgeligt meget mere effektivt bare at komme med truslen så masser af firmaer og udviklere kan have den hængende over hovedet.

Jesper, synes du det er specielt underligt at folk er meget kritisk indstillede overfor meget af det der kommer fra Microsoft? Du har helt ret i at der er en del der ikke bringer meget relevant til diskussionen, men det kan ikke overraske.

Jesper Lund Stocholm

> Jesper, synes du det er specielt underligt at folk
> er meget kritisk indstillede overfor meget af det
> der kommer fra Microsoft?

Nej - det synes jeg ikke. Jeg har selv en "sund skepsis" overfor hvad Microsoft siger og gør, men det er ikke udgangspunktet for min holdning til formatkrigen. På mig virker det som om, at det for flere andre (ingen nævnt, ingen glemt) netop er grundlaget for deres forsvar for ODF - nemlig at de er imod Microsoft. Der er mange gode grunde til at være skeptiske overfor MS-udtalelser og der er mange gode grunde til ikke at glemme Microsofts historik, men når du spørger mig, så er det barnagtigt at bruge det som argument imod OOXML. Hvad med i stedet at kigge på, hvilke muligheder de enkelte formater giver på godt og ondt, så vi kan skabe de bedste muligheder for værdi og vækst i den offentlige forvaltning?

> Du har helt ret i at der
> er en del der ikke bringer meget relevant til
> diskussionen, men det kan ikke overraske.

Næeh - men derfor kan jeg jo godt være trist over det :o) Præmissen for stort set alle indlæg i diskussionerne er reelt teoretiske af natur og derfor giver de ikke mening i en pragmatisk verden - og specielt ikke, hvor politikere skal tage stilling. Et glimrende eksempel på dette er diskussionen om hvorvidt ODF eller OOXML overholder de tre teser fra aabenstandard.dk . Den første tese taler om en fuldstændig specifikation. Der vil jeg sige, at ODF ligger på 10 og OOXML på 9 på en skala fra 1-10. Min anke her er, at det er muligt, at der i ODF ikke er eksempler på dele, hvor der står "Hemmelig del" som legacy-attributterne i OOXML, men det er ikke nok kun at kigge på det. Man skal altså ikke glemme, at der i ODF er en lang række egenskaber, der ikke er i selve specifikationen - herunder fx hvordan man laver en formel i et regneark. Set ud fra 1-10 skalaen, så "vinder ODF over OOXML", men det er en teoretisk sejr, for ude i den virkelige verden er det noget hø, hvis jeg skal lave en parser til et format, hvor der er sektioner, der slet ikke er specificeret i spec eller hvor jeg skal kigge i kildekoden for andre applikationer for at se, hvordan jeg skal løse en opgave.

René Løhde

Finn,

” med næsten ethvert grafisk visningsprogram/redigeringsprogram kan man konvertere...”

Jeg er enig – det er applikationer som skaber interoperabilitet og standarder er bare en leverance i den process.

” MS - at komme efter konverteringsværktøjerne begge veje OG evt. gøre kildekoden til disse åbne for alle”

FYI - Det er lige præcist hvad Microsoft har gjort på Sourceforge!

Jacob B,

De to standarder er forskellige i designmål og funktionalitet f.eks på tilgængelighed, formularer, egne xml vokabularier. Tabel tilgangen er væsentlig forskellig ...det er nogle af de ting jeg umiddelbart hæfter mig ved.

Se evt. Eksempel på: http://blogs.msdn.com/renel/archive/2007/04/27/brugerdefineret-xml.aspx

Christian,

Hvor er OpenXML ” ikke er åben nok” – og du må meget gerne lave en sammenligning med ODF på de udvalgte områder?

Mikkel,

Min sammenligning var ikke TLS vs. SSL, men (TLS/SSL) vs. WS-Security.

Angående side antallet – den diskussion har jeg taget et andet sted og jeg må henvise dertil:
http://blogs.msdn.com/renel/archive/2007/02/14/3-musketerer-p-v2.aspx

Georg,

Betyder det at vi kan fravælge en standard med henvisning til at funktionalitet og features muligvis implementeres i en anden standard?

Jacob V,

Enig i dine betragtninger - på nær det med garantien :-)

Simon,

Jeg mener at der skal være plads til begge og jeg vil ikke stå i flere valg mellem åbne standarder fremover (og jeg vil i særdeleshed ikke have det udlagt til politikere og embedsmænd). Hvis nogen mener at der skal være en ”one-to-rule-them-all” tilgang til hele standards diskussionen, så lad os tage den snak.

Det er det jeg vil sige med min post.

Tak, for link. Har opdateret!

Poul-Henning,

Det betyder vel ikke at TIFF, JPEG og PNG ikke kan sameksistere. De har fundet hver sin plads i markedet.

Poul-Henning vi har jo tidligere diskuteret dette (hvad mangler og hvad er ikke dokumenteret) og glæder mig til at snakke videre, men kan du ikke gøre mig en tjeneste og se denne sammenligning (det er ikke 6000 sider!):

http://blogs.msdn.com/brian_jones/archive/2007/02/20/beyond-the-basics.aspx

...og derefter fortælle mig om du stadig mener at ” ODF klarer sig bedre på alle disse punkter”.

Jesper K,

Jeg har godt set PTO’s gennemgang og har kommenteret på dem i den tråd. Der er stadig intet i man optik, som gør den ene eller den anden mere åben.

Jakob R,

Enig, og dit spørgsmål til Jesper Laisen er lidt det jeg håbede at Version2 ville stille i stedet for ”vil du have en eller to standarder?”.

Peter M,

Peter Mogensen... er du den Peter Mogensen, som jeg snakkede med om dette for et par år siden på cw.dk? If so – godt at høre fra dig igen!

Min udlægning af formål og design – ODF lavet for at skabe et åbent format til text, regneark og præsentation med mest mulig genbrug af andre standarder. Lavet med stor vægt på autonomi hos de udviklere som skal implementere. Primær brug for tekstdokument – skal opfylde traditionelle dyder, som basal formatering, tabeller, billeder og det brugerne kender til fra andre applikationer i dag.
OpenXML lavet for at få et åbent format, som er kompatiblet med den eksisterende base af kontordokumenter. Primær brug for tekst dokument – Som ODF + lavet til kollaboration og fødested for strukturerede data til behandling i andre IT systemer.

Peter J C,

Jeg kan ikke se eller gætte din mening om hvorfor OpenXML ikke kvalificerer i de to krav du har opsat. Kan du uddybe?

Jørgen,

Min pointe er at de valg skal lægges ud til de brugere, som i sidste ende skal skrive og bruge software og ikke til politikere og embedsmænd.

Angående Microsoft ry og rygte - ja, vi har et bully rygtee og det læser jeg om hver dag og får en masse henkastede bemærkninger. Ikke desto mindre opvejes det af at have nogle meget kloge og gode kollegaer, som f.eks Jon Udell
(se http://weblog.infoworld.com/udell/2006/12/08.html#a1574) - læg mærke til at han bl.a tager til Microsoft fordi han mener at virksomheden har ændret sig.

I den aktuelle diskussion savner jeg faktisk lidt at de, som i 2003 sagde at Microsofts Reference Schemas for WordprocessingML og SpreadsheetML var en enlig svale anerkender at det var en oprigtig beslutning, som er blevet fulgt op af yderligere tiltag.

Jesper S L,

Hvor får du luft til at have så mange samtaler kørende? U thread man!

Jan Flodin

jesper, du skriver :"Nej - det synes jeg ikke. Jeg har selv en "sund skepsis" overfor hvad Microsoft siger og gør, men det er ikke udgangspunktet for min holdning til formatkrigen. På mig virker det som om, at det for flere andre (ingen nævnt, ingen glemt) netop er grundlaget for deres forsvar for ODF - nemlig at de er imod Microsoft"

Lad mig indrømme at det for mit vedkommende er en rigtig antagelse, men faktisk synes jeg også at det måske er det mest relevante argument overhovedet.

Hvorfor har vi debatten om to formater? Fordi Microsoft ikke ville støtte ODF, men da presset blev for stort ændrede MS strategien til at støtte åbne formater - men altså kun det, de selv definerede.

Selvfølgelig skal man passe på med overfortolkninger, men i min optik er der ingen tvivl om at hele debatten derfor i bund og i grund drejer sig om penge. Taber Microsoft striden om formater er hele deres kontorpakke i farezonen, og derfor opfandt de OOXML og smed det ind i en meget teoretisk debat om formater og formatforskelle. Klart spin for hele denne debat er jo ganske irrelevant, hvis blot MS havde accepteret at håndtere ODF i forbindelse med udveksling af dokumenter med andre systemer.

Dermed er Microsofts historik lige pludselig det bedste argument mod OOXML. Vælg OOXML og du har samtidig valgt MS kontorpakker, MS operativsystem på din desk top(for det kører jo ikke på andet), MS server operativsystem og alt det andet, som på denne måde trækkes ned over hovedet på dig - uanset EU kommissionens forsøg på at sikre konkurrencen.

I det perspektiv er det slet ikke relevant hvad det koster at skifte til ODF og om du skal give køb på nogle features.

Du bliver simpelthen nød til at sikre din frihed, og ja - det lyder som en religiøs kamp, men det gør det ikke mindre rigtigt.

PS: Jesper, jeg skal gerne hjælpe dig med at lave workflowsystemer uden OOXML (men jeg tror nu godt du kan det allerede).

Christian Dias Løgberg

Rene:
Specifikationer som "autoSpaceLikeWord95" og mange andre, gør at jeg ikke kan sætte mig ned med OOXML-specifikationen og lave en implementation, der viser dokumenter korrekt. Hvorfor ikke slippe af med denne bagudkompatibiltet ved at indstille den korrekte værdi i "autoSpace"-parameteren i stedet for at benytte sådan en kryptisk betegnelse.
Det svarer til at der i en kogebog står at lasagnen skal bages ligesom <random opskrift> og ikke bare fortæller at den skal have 45 min ved 200C...

Dennis Krøger

Sjovt nok ignorerer du, at det eneste PNG og JPEG har til fælles, er at de kan bruges til at vise grafik.

PNG er velegnet til billeder med få farver, og med "skarpe" overgange imellem dem. PNG er elendigt til store fotografier.

JPEG er velegnet til fotografier, men elendig til simple billeder.

Det tilsvarer meget godt office formaterne kontra PDF, som ingen er i tvivl om har sin relevans.

En meget mere relevant sammenligning er GIF og PNG: De gør det samme, men GIF er ikke åben, og alligevel den eneste førsterangs indbygger i et ret brugt MS program, PNG's transparens understøttes ikke, kun GIF's (Er det egentlig stadig sådan i IE7?)

ODF og OOXML gør det samme, men OOXML er ikke (rigtigt) åben, og alligevel den eneste førsterangs indbygger i et ret brugt MS program (ODF kan ikke gemmes som default, uanset om man har installeret plugin).

Jesper Lund Stocholm

> Lad mig indrømme at det for mit vedkommende er en
> rigtig antagelse, men faktisk synes jeg også at
> det måske er det mest relevante argument
> overhovedet.

ok ... så længe vi har det på det rene :o)

> Hvorfor har vi debatten om to formater? Fordi
> Microsoft ikke ville støtte ODF, men da presset
> blev for stort ændrede MS strategien til at
> støtte åbne formater - men altså kun det, de
> selv definerede.

Jeg synes faktisk, at det er vigtigere, at Microsoft endelig har fundet ud af, at det kunne være en god idé med et åbent format end at de blev tvunget til det (jeg er jo pragmatiker). I øvrigt viser det med al tydelighed, at Microsoft ikke er en urørlig mastodont, men én der faktisk godt kan påvirkes. Hvis man ser på beskyldningerne imod Microsoft, så kunne man ellers forledes til at tro det modsatte.

> Selvfølgelig skal man passe på med
> overfortolkninger, men i min optik er der ingen
> tvivl om at hele debatten derfor i bund og i
> grund drejer sig om penge.

Jeg er fuldstændig enig - jeg er 100% sikker på, at hovedidéen for Microsoft, IBM, Sun, Google og andre er markedsandele og ikke kampen for den lille mand.

> [..] Klart spin for hele denne debat er jo
> ganske irrelevant, hvis blot MS havde accepteret
> at håndtere ODF i forbindelse med udveksling af
> dokumenter med andre systemer.

ODF er udviklet på basis af dokumentformatet for OpenOffice og OOXML er udviklet på basis at dokumentformatet for MS-Office. At blive ved med at snakke om, at "de jo bare kunne ..." er ved at være trættende. For mig at se er /formaterne/ og deres muligheder/umuligheder det vigtige og ikke de historiske årsager til, at de er blevet som de er.

> Vælg OOXML og du har samtidig valgt MS
> kontorpakker, MS operativsystem på din desk
> top(for det kører jo ikke på andet), MS server
> operativsystem og alt det andet, som på denne
> måde trækkes ned over hovedet på dig - uanset EU
> kommissionens forsøg på at sikre konkurrencen.

Ordet FUD smides gerne imod udtalelser fra Microsoft, men dette er da et klokkeklart eksempel på, at det kan komme fra den anden lejr. Jeg synes reelt ikke, at der er belæg for nogen af dine påstande, og jeg mistænker at årsagen til dit udfald er, at du ikke selv har kigget i OOXML-standarden.

> I det perspektiv er det slet ikke relevant hvad
> det koster at skifte til ODF og om du skal give
> køb på nogle features.

Enig - omkostningerne er for mig ikke så vigtige - om prisen end er 40 mil eller 500 mil. Det vigtige er hvad vi kan bruge formaterne til i den offentlige forvaltning.

> PS: Jesper, jeg skal gerne hjælpe dig med at
> lave workflowsystemer uden OOXML (men jeg tror
> nu godt du kan det allerede).

Det har jeg i hvert fald fortalt min chef ;o) Men OOXML drejer sig ikke om at kunne bygge workflowsystemer som sådan men om at kunne trække endnu mere værdi ud af dem end vi kan nu.

René Løhde

Dennis,

Bekræfter du min artikel med at der er forskelle eller?

Ja, PNG er i IE7!

Hvis du mener PDF har relevans, ser du så ikke bort fra B103's krav om åbne standarder? Men jeg er i øvrigt enig - selvfølgelig skal det offentlige DK have lov til at bruge PDF!

Jeg kan forholde mig til Åbne standarder som det er defineret i B103. Hvis der skal gradbøjes, som du gør - "ikke (rigtigt) åben" - så er jeg nød til at vide hvad du mener eller hvad det betyder for at vi kan diskutere.

Jesper,

http://sourceforge.net/projects/odf-converter/

Georg Sluyterman

> Georg,
>
> Betyder det at vi kan fravælge en standard med
> henvisning til at funktionalitet og features
> muligvis implementeres i en anden standard?

Idet standarden vedligeholdes i et åbent forum, kan den udvikless, og jeg mener det er urealistisk at tro, at funktioner som f.eks. OpenFormula ikke kommer med i næste version.

EOOXML vedligeholdes ikke i et åbent forum (ECMA), så hvor let er det at få ændringer igennem der?

Jeg mener der er så meget overlap mellem de to standarder at det vil være dumt at vedtage at bruge dem begge. Staten slipper for at konvertere frem og tilbage ved blot at vælge ODF.

Mikkel Høgh

René Løhde referer til en blog på msdn hvor der tales om manglende dokumentation af de extensions som blandt andet OOo bruger ifbm. ODF - og det er ganske rigtigt et problem.
Men dog et problem der relativt hurtigt kan løses - dokumentationen kan altid komme senere...

Derimod faldt jeg den anden dag over en ret foruroligende analyse af Microsofts EOOXML, hvor der blandt andet bores en del i at Microsoft har valgt at basere det meste af EOOXML på deres egen teknologi i stedet for anerkendte standarder.

Man har f.eks valgt at bruge:
* "DrawingML" i stedet for SVG
* et unavngivet format i stedet for MathML
* Deres egen uprøvede hashing-algoritme i stedet for f.eks ISO 10118-3 ("Whirlpool"), SHA256(m.fl.) eller endda MD5.

Der er også en fejl i deres implementering af den gregorianske kalender, de vælger at se bort fra ISO standarder for formatering af datoer og landekoder (hhv. ISO 8601 og ISO 639).

Og meget mere - se http://www.grokdoc.net/index.php/EOOXML_objections

Jeg synes det er ærgeligt at Microsoft ikke har benyttet lejligheden til at basere mere af deres infrastruktur på åbne standarder.

Det betyder også at der for den stakkel der får behov for at implementere EOOXML i sin software får brug for at implementere alle Microsofts forskellige hjemmebryggede standarder...

Kim Schulz

>Ja, PNG er i IE7!

Ja og understøttelsen er ca lige så elendig som i IE6! hvis ikke din skærm står til rette opløsning, farvevalg osv. og hvis ikke sol-måne-og-stjerner står på linje, så viser den stadig alpha som sort eller anden misfarvning - Det er da hvis den ikke går ned når den forsøger at loade filen.

>FYI - Det er lige præcist hvad Microsoft har gjort på Sourceforge!
Antager du mener http://odf-converter.sourceforge.net/
Det projekt er IKKE et MS projekt, men et projekt som oprindeligt blev startet af en flok franskmænd. De lavede flere udgivelser før at MS så en mulighed i det og kom ind over med finansiering. Noget andet er så at det er mildest talt elendigt så snart at dokumenterne er bare lidt avancerede og udfaldet er at dokumentet ser helt forkert ud. Det er en begyndelse, men det er ikke løsningen på det dokument problem vi har her og nu.
Netop http://www.grokdoc.net/index.php/EOOXML_objections giver et meget godt billede af hvorfor EOOXML aldrig bør vælges, ja hvorfor det nærmest helt burde forbydes. Det er skræmmende hvilke tåbelige valg der er foretaget i det format - det virker mildest talt som om der har været 2 formål:
1) andet end MS produkter skal aldrig kunne komme til at bruge det.
2) smække et hurtigt "åbent" format sammen da det pludselig var dette der var på valg - de kunne jo miste markedsandel.

Dennis Krøger

> "Bekræfter du min artikel med at der er forskelle eller?"

Selvfølgelig er der forskelle, men ingen der retfærdiggør to standarder.

> "Ja, PNG er i IE7!"

Det var det også i IE6, men kan den bruge PNG's transparency ordentligt, eller er det stadig ubrugeligt?

> "Hvis du mener PDF har relevans, ser du så ikke bort fra B103's krav om åbne standarder? Men jeg er i øvrigt enig - selvfølgelig skal det offentlige DK have lov til at bruge PDF!"

PDF har relevans, som et format der er tilstrækkeligt anderledes, til at man kan sige at der er brug for det (eller noget lignende), dermed bestemt ikke sagt at det nødvendigvis skal benyttes, det er trods alt langt fra åbent. Desværre er der vist ikke rigtig noget alternativ, tror ikke at PostScript er nok, men der er sikkert en masse der kan korrekse mig hvis jeg tager fejl (hvad jeg håber at jeg gør). Havde MS egentlig ikke noget på vej, og i så fald, er/bliver det et åbent format?

> "Jeg kan forholde mig til Åbne standarder som det er defineret i B103. Hvis der skal gradbøjes, som du gør - "ikke (rigtigt) åben" - så er jeg nød til at vide hvad du mener eller hvad det betyder for at vi kan diskutere."

Henvisninger til skjulte dele, turen igennem ECMA uden rigtige rettelser, fordi MS allerede havde implementeret formatet, og ingen uafhængig styring af formatet er lidt af det.

michael rasmussen

For lige at præcisere:

PDF i versioner <= 1.4 er en ISO standard.

PDF/A-1 => ISO 19005-1; Document management - Electronic document file format for long-term preservation

PDF/X => ISO 15930-6; a standard which faciliates prepress digital data exchange using PDF

Så jo Rene, anvendelse af PDF i den offentlige forvaltning vil være i overensstemmelse med B103, da forvaltningens anvendelse af PDF vil være enten PDF/A eller PDF/X

/Michael

Jesper Lund Stocholm

> René Løhde referer til en blog på msdn hvor der
> tales om manglende dokumentation af de extensions
> som blandt andet OOo bruger ifbm. ODF - og det er
> ganske rigtigt et problem.
> Men dog et problem der relativt hurtigt kan løses
> - dokumentationen kan altid komme senere...

Du har misforstået det. Det drejer sig ikke om, at der er sektioner i spec, hvor der står "dokumentation mangler, kommer senere". Det drejer sig om, at der allerede nu er sket en branching af ODF, hvor de forskellige applikationer har lavet deres egne udvidelser og dermed er der sektioner i et ODF-dokument, hvis indhold er afhængigt af, hvilken applikation, der har lavet dokumentet. Denne del kan jo ikke "altid komme senere", da man jo ikke kan lave en udtømmende liste over de applikationer, der kan lave et ODF-dokument.

Man kan jo naturligvis indvende, at det kan man jo aldrig undgå, når flere applikationer skal implementere understøttelse af et format. Problemet med ODF er, at det direkte er understøttet i specifikationen. Så længe man gør opmærksom på, at her er en udvidelse og markerer det med den korrekte namespace-reference til sin egen applikation såsom OpenOffice.org, KOffice, Google Docs eller lignende, så overholder man formatet. Men dermed laver man reelt en specifikation, der aldrig kan blive fuldstændig, da dokumentationen for indhodlet af en del af et ODF-dokument evt skal findes i den konkrete implementering af en eller /anden/ Office-suite.

Jesper Lund Stocholm

> Idet standarden vedligeholdes i et åbent forum,
> kan den udvikless, og jeg mener det er urealistisk
> at tro, at funktioner som f.eks. OpenFormula ikke
> kommer med i næste version.

Det tror jeg, at du har ret i ligesom jeg tror, at næste udgave af OOXML kommer til at løse nogle problemer i den nuværende version.

Men jeg synes ikke rigtigt, at diskussionen om fremtidigt indhold i hverken OOXML eller ODF er interessant i forhold til diskussionen om valg af formater. Folketingspolitikernes valg står sandsynligvis imellem ISO-versionen af ODF, nemlig v1.0 og ECMA-versionen af OOXML. Om der i fremtiden kommer udvidelser/fornyelser til formaterne er for så vidt irrelevante, da det tilladte udvekslingsformat med det offentlige ikke kan drage optimal nytte af det.

Poul-Henning Kamp

Rene, du har ikke forholdt dig til indholdet i mit svar, bare henvist til noget M$ propaganda.

Jeg prøver med noget tykkere krydsfiner:

Forestil dig at TIFF standarden var 600 sider og PNG var 6000 sider.

Ville du så også argumentere for at det var nødvendigt at introducere PNG, bare fordi "nogen" ikke kan lide TIFF ?

Poul-Henning

Jesper Lund Stocholm

> Forestil dig at TIFF standarden var 600 sider og PNG var 6000 sider.

Jeg forstår simpelthen ikke, at du bliver ved med at tæske på den gamle hest. Grunden til at ODF er på 600 sider (og rent faktisk er den på 706 sider) er, at den refererer til en lang række andre standarder herunder SVG. Men hvis du insisterer på at tælle sider, så skal de tilsvarende elementer (fx VML er det vist) jo fratrækkes sideantallet for OOXML. Derudover er der jo i OOXML en række elementer, der ikke findes i ODF - fx en specifikation af formelsyntaks. Har du husket at trække disse "overflødige" sider fra OOXML-sideantallet? Det er fint nok, at du vil diskutere sideantal, men du må komme frem med nogle mere intelligente betragtninger end brutto-antallet for de to rapporter.

Poul-Henning Kamp

Grunden til at jeg bliver ved med at tæske på "denne gamle hest" er at der fandme ikke er nogen grund til at blive ved med at opfinde det varme vand.

Forfattere inkluderer ikke en hel parafrase af biblen i deres bøger, de henviser blot til den.

Hvis Microsoft mener at deres grafikformat er bedre end SVG så skal de få det standardiseret som sådant og få OOXML til at henvise til denne standard.

Men partitionering og modularisering er to datalogiske grundprincipper som Microsoft aldrig har forstået og med deres markedsdominans er der mange, inklusive tilsyneladende dig, der ikke fatter at det er en vigtig måde at skære arbejdsbyrden ned i pakker der kan håndteres af den størrelse hjerne vi mennersker er udstyret med.

Som Dijkstra sagde for mange år siden:

I have only a small brain, and must live with it"

Læs venligst hele hans utroligt fremsynede paper:

http://hp.fciencias.unam.mx/~jloa/CC/dijkstra1i.html

Microsoft ser omfanget af OOXML som en stor fordel, for det er en enorm barierre for deres konkurrenter.

Poul-Henning

Jens Kolberg

Vedr. "custom schemas" kunne det vel være interessant at se hvad OASIS OpenDocument Community selv har at sige om dette: (Fra: http://opendocument.xml.org/book/print/21)

Does OpenDocument support custom schemas?

The term "custom schema support" frequently is used to describe the possibility to interleave an office application schema with XML tags from some other schema. Because this is a feature of XML and XML Namespaces in general, it is supported by OpenDocument. It is important to distinguish between the OpenDocument format and applications that implement it, however. No applications at this point exploit this feature, but this is inherently supported by the OpenDocument format.

Another definition of "custom schema" support is the possibility to include an instance of a non-office-schema into an office document. This feature is provided by OpenDocument, due to its partial inclusion of the W3C XForms Recommendation.

Kristian Larsen

Jesper, det må formodes at være v 1.1 eller v 1.2 som vil blive implementeret:
http://www.oasis-open.org/news/oasis-news-2007-02-14.php

Dette da der er en Liaison mellem OASIS og den komittee som arbejder med ODF i ISO regi, som det kan ses her:
http://www.iso.org/iso/en/stdsdevelopment/tc/tclist/TechnicalCommitteeDe...

Mht. sideantal så er den officielle ISO udgave af v 1.0 på 722 sider - vil dog formode der er noget "fyld" - ihvertfald hvis de minder bare lidt om red og white papers fra forsk. vendors.

Jesper Lund Stocholm

> Grunden til at jeg bliver ved med at tæske på
> "denne gamle hest" er at der fandme ikke er nogen
> grund til at blive ved med at opfinde det varme
> vand.

Nej - og her er vi fuldstændigt enige.

> Men partitionering og modularisering er to
> datalogiske grundprincipper som Microsoft aldrig
> har forstået og med deres markedsdominans er der
> mange, inklusive tilsyneladende dig, der ikke
> fatter at [bla bla bla] ...

Rolig Poul-Henning. Du har aldrig set udtalelser fra mig, der siger at man ikke skal bygge på nuværende standarder, og netop den manglende anvendelse af eksisterende standarder er netop en af mine anker imod OOXML. Jeg så også helst, at de havde anvendt fx SVG i OOXML, men de har åbenbart ment, at deres eget grafik-format var bedre til deres formål. Men det er også dét, der er argumentet og ikke sideantallet. Hvis jeg vil implementere understøttelse for ODF i en applikation - og ikke ønsker at anvende tredjeparts-komponenter (det er ikke et urealistisk scenarium at blive bedt om af en kunde), så nytter det jo ikke noget, at jeg blot kigger på de 700 sider for ODF. Her er jeg også nødt til at kigge på de refererede standarder og implementere disse. /Derfor/ er det ikke nok at kigge på bruttosideantal og derfor fornedrer du diskussionen, når du bliver ved med at trække argumentet frem. Hvis du insisterer på, at det bedste argument er 6000vs600, så kvalificér det venligst, så det reelt giver mening.

Dennis Krøger

"Hvis jeg vil implementere understøttelse for ODF i en applikation - og ikke ønsker at anvende tredjeparts-komponenter (det er ikke et urealistisk scenarium at blive bedt om af en kunde), så nytter det jo ikke noget, at jeg blot kigger på de 700 sider for ODF."

Så fordi der er 3 snævertsynede kunder ud af 100, er det et argument for at den 900% større specifikation IKKE er et problem generelt?

Det ER et problem, uanset hvor lidt du kan lide at det er det.

Poul-Henning Kamp

Jesper,

Har du nogen sinde siddet med en kontrakt, specifikation eller standard på over 1000 sider og været ansvarlig for at at den blev efterlevet til punkt og prikke ?

Hvis du ikke har den oplevelse bag dig, så kan jeg godt forstå at du ikke mener at "600 vs. 6000" er et argument i sig selv.

Hvis du har prøvet det, så ved du også, at ingen jordisk sjæl har en chance for at implementere OOXML på 6000 sider, bortset fra Microsoft der blot skulle beskrive hvad deres programsuite foretager sig.

Poul-Henning

Michael Jensen

Hej René.

Spændende at du blander dig i debatten!

En af grundende til at se på åbne dokumentformater i Danmark er, (så vidt jeg kan se) muligheden for øget konkurrence på kontorapplikationsområdet. Jeg kan godt se at dette ikke er i Microsofts interesse, men jeg mener det er i alle andres interesse - inkl. forbrugernes.

Om det er ODF eller OOXML (og jeg mener det er fornuftigt at foretage et valg), som skal benyttes synes jeg skal afhænge af, hvordan de to standarder udvikles.

Med ODF har alle interesserede parter mulighed for at komme med input til standarden, som alle øvrige SW-udviklere får adgang til samtidig.

Dette mener jeg ikke gør sig gældende med OOXML, som Microsoft jo styrer udviklingen af. Det man kunne frygte er, at hvis denne standard bliver valgt vil alle øvrige SW-udviklere få adgang til standardens nye muligheder, når Microsoft allerede har udsendt deres nyeste kortorapplikation.

Ulrik Gerdes

Okay, okay og ...Undskyld! Jeg fik bare sådan lyst, herude fra sidelinien i det virkelige liv, til at heppe på min favorit i denne mærkværdige hybrid af en bokse-/skak-/rugby-/trivial pursuit-/mudderbrydning-/bridge-dyst.

Når nu engang kampen er ovre, og I har været i koldt brusebad alle sammen (ODF'erne gerne i længere tid), kunne vi så ikke blive enige om, at det smarteste for den fortsatte naturlige evolution af software ville være, at der findes mindst to standarder? Gerne flere, men mindst to!

Forestillingen om at vi kun skal have én standard giver mig oprigtigt talt myrekryb. Især hvis det skulle blive ODF.

Peter Juhl Christiansen

Mit første indlæg:
koger man kravet til en dokument standart i det offentlige ned, er der som jeg ser det et "teoretisk" og et pratisk krav:

-Det teoretisker er at det skal være en standart, udfra vedtagede definoioner og godkendt som sådan.

-Det prakiske: Der skal findes flere produkter til visning og editering, gerne også gratis produkter således at envher borger uden at blive pålagt en ekstra udgift kan sende og modtage dokumenter til/fra det offentlige.

Rene skriver

>Jeg kan ikke se eller gætte din mening om hvorfor
>OpenXML ikke
>kvalificerer i de to krav du har opsat. Kan du uddybe?

Det teorretiske troede jeg var klart, det er IKKE en ISO standart.

Det praktiske handler om at der som jeg er underrettet IKKE findes implimentationer (udover MS) der 100% implimenteerer standarten, altså findes der IKKE egentlige alternative produkter borgerer og eller offentlige myndigeder kan vælge mellem hvis de skal håndterer OOXML.

Man kan gradbøje synspunktet en smule ved at sige man bør vælge den standart der skaber størst konkurence og valgfrihed, altså IKKE OOXML.

Jesper Lund Stocholm

(aah ... lang weekend)

> Har du nogen sinde siddet med en kontrakt,
> specifikation eller standard på over 1000 sider og
> været ansvarlig for at at den blev efterlevet til
> punkt og prikke ?

Nej - men det er heller ikke den knag jeg hænger mit argument på.

> Hvis du har prøvet det, så ved du også, at ingen
> jordisk sjæl har en chance for at implementere
> OOXML på 6000 sider,

Mit argument er jo, at det behøver vi heller ikke. 99.999% af alle os, der kommer til at arbejde aktivt med dokumentformaterne (heri naturligvis ikke regnet de, hvis eneste interface til formatet bliver "Gem som..." i deres foretrukne kontorpakke ... og debatterne på v2.dk) vil aldrig komme til at have behov for at implementere 100% af spec i deres kode. Vi vil komme til at anvende udvalgte dele af formatet, når vi skal danne fx ODF-dokumenter eller læse ODF-dokumenter. Dermed kommer spec for ODF og OOXML til at fungere som opslagsværker og ikke kogebog for implementering af hele spec. Fuld implementering af spec er reelt kun relevant for producenter af kontorpakker, og du skal ikke bilde mig ind, at folkene bag OpenOffice.org eller "the three slayers" (IBM, Sun og Google) ikke magter at implementere OOXML.

:o)

Jesper Lund Stocholm

> The term "custom schema support" frequently is
> used to describe the possibility to interleave an
> office application schema with XML tags from some
> other schema. Because this is a feature of XML and
> XML Namespaces in general, it is supported by
> OpenDocument.

Det lyder faktisk ret spændende, og jeg vil godt lige kigge på det. Det ser dog ud til, at argumentet er, at "da Custom Schemas er xml og ODF er xml, så understøtter ODF Custom Schemas" [0] og umiddelbart synes jeg, at den antagelse kunne bruge lidt mere kød. Har du prøvet at lege med, hvordan det evt virker i ODF?

[0] Wohoo ... trekantsregel!

Jesper Lund Stocholm

> Jesper, det må formodes at være v 1.1 eller v 1.2
> som vil blive implementeret:

Jamen hov ... ODF v. 1.1 er jo ikke en ISO-standard. Nu må man jo så forvente, at alle de debattører, der har råbt og skreget på OOXMLs manglende ISO-certificering, at de ligeledes kaster sig over dig og siger, at man ikke kan bruge en standard, der ikke er ISO-certificeret.

... men det gælder måske kun, hvis standarden er OOXML?

;o)

Jesper Lund Stocholm

Dennis,

> Så fordi der er 3 snævertsynede kunder ud af 100,
> er det et argument for at den 900% større
> specifikation IKKE er et problem generelt?

Og her gik jeg og troede, at Open Source betød større, friere og bedre valgmuligheder for valg og anvendelse af software, da man kan kigge med "bag gardinerne" i kraft af den tilgængelige kildekode. Men hvis jeg af en eller anden grund skulle /fravælge/ Open Source, så er jeg tilsyneladende snævertsynet.

> Det ER et problem, uanset hvor lidt du kan lide
> at det er det.

Tja - men uanset om du kan lide det eller ej, så er det ikke altid "tilladt" at finde en OSS-komponent og anvende den i noget kommerciel software. I de tilfælde er det jo ligegyldigt om "grund-spec" er på 600 sider - her skal man jo også ud og implementere fx SVG, MathML og de andre standarder, der er refereret i ODF.

Jørgen Ramskov

Rene:

"Angående Microsoft ry og rygte - ja, vi har et bully rygtee og det læser jeg om hver dag og får en masse henkastede bemærkninger. Ikke desto mindre opvejes det af at have nogle meget kloge og gode kollegaer, som f.eks Jon Udell
(se http://weblog.infoworld.com/udell/2006/12/08.html#a1574) - læg mærke til at han bl.a tager til Microsoft fordi han mener at virksomheden har ændret sig."

Jeg ville ønske det var sandt! Desværre viser de 3 eksempler jeg nævnte tidligere et noget andet billede. Endnu et eksempel: http://www.linux.com/article.pl?sid=07/04/16/2019244

Det omhandler Microsoft lobbyister der lynhurtigt sørger for at få ændret et lovforslag om åbne standarder.

Ulrik Gerdes:
"Når nu engang kampen er ovre, og I har været i koldt brusebad alle sammen (ODF'erne gerne i længere tid), kunne vi så ikke blive enige om, at det smarteste for den fortsatte naturlige evolution af software ville være, at der findes mindst to standarder? Gerne flere, men mindst to!

Forestillingen om at vi kun skal have én standard giver mig oprigtigt talt myrekryb. Især hvis det skulle blive ODF."

Det handler om hvad der er det smarteste for det offentlige (den danske stat, kommunerne, osv.) at vælge. Jeg kan ikke se det fornuftige i at vælge 2 formater.

Hvad er det du ikke kan lide ved ODF?

Kristian Larsen

Du mener altså at sandsynligheden for at hverken ODF v1.1 eller v1.2 ikke når at blive godkendt inden vi skal implementere dette i løbet af de 5 år som Rambøll går ud fra (og eftersom IT&TS ikke siger andet, må det jo være planen....). Men ok lad os bare sige 1 kvartal 2008.

Standarden er godkendt, og det er altså et spørgsmål om at opdateringen skal godkendes af ISO kommitteen som er udfærdiget af en af denne kendt liaison.

Jeg kan ikke tro andet end at som minimum v1.1 er godkendt til den tid, ellers står det ihvertfald skidt til hvis det ligefrem er således at OOXML skal behandles hurtigere end godkendelse af opdateringen af en nuværende standard.

Jesper Lund Stocholm

... spørger du mig om noget ... eller?

Men jeg er da glad for, at vi nu kan lægge diskussionen om ISO/ikke-ISO fra os, da OOXML sandsynligvis er godkendt som ISO-standard indenfor de 5 år Rambøll går ud fra.

Lad os så komme videre og snakke om noget mere interessant.

René Løhde

Georg,

Jeg kan læse af din kommentar at ECMA ikke er en standardiseringsorganisation, som kan bruges i en B103 kontekst og at det bl.a er derfor at OpenXML ikke skal være en standard. Jeg har svært ved at se hvorfor ECMA ikke er en standardiseringsorganisation.

Mikkel,

Skal jeg forstå det således at ” dokumentationen kan altid komme senere...” når det gælder ODF, mens OpenXML underlægges en global smædekampagne på det samme område?

Angående SVG – jeg ved ikke hvorfor der ikke blev brugt SVG i OpenXML, men vil gerne undersøge det hvis det kan have din interesse.

Angående MathML, så var det et fravalg pga arkitektur i applikationen, der ikke stod mål med designmål af OpenXML – det er dog muligt at få transformeret den repræsentation som findes i OpenXML til MathML via XSLT som kan downloades fra et eller andet sted (som jeg godt kan finde frem hvis nogen har det ønske!)
Hvis du mener at hasing algoritmer og MathML support bør afgøre om en dokumentstandard skal kunne bruges i det offentlige Danmark og er udslagsgivende så tror jeg at du vil blive overrasket over hvor mange andre problemer af signifikant større betydning du vil løbe ind i f.eks med ODF.

Dato issue – det er ikke en fejl, men en design beslutning truffet for at være kompatibel med en gammel fejl oprindeligt opstået i Notes!

Kim,

Projektet på Sourceforge er financieret og projektledet af Microsoft – deraf min ordlyd.

Mig bekendt er der minimum et andet produkt som bruger OpenXML udover Office 2007.

OpenXML blev ikke ”smækket” hurtigt sammen – der har været under udvikling igennem 10 år og forgængeren blev ”åbnet” i 2003.

Dennis,

Jow – der var tale om at Microsoft ville lave og standardisere XPS. Så vidt jeg er orienteret er dette stadig tilfældet og i pipeline.

Der er ikke skjulte dele! - der er dele, som det er overladt til udvikleren selv at implementere – nøjagtigt som det er tilfældet med mange formateringsattributter i ODF.

Angående ændringer i OpenXML formatet under standardisering - der var rettelser i OpenXML under ECMA standardiseringen og disse blev implementeret i Office 2007.

Angående uafhængighed af Microsoft - ECMA er vel uafhængig styring!?

Michael R,

Wow – det var jeg ikke klar over – det skulle da vist have været skrevet ind i kravene til eDag1.

Poul-Henning,

Hvis de to standarder dækkede det samme område og samme formål ville jeg naturligvis vælge den på 600 sider! Det er bare ikke tilfældet for ODF/OpenXML.

Hvis du virkelig mener at side antallet har så stor betydning – så tillad mig en øvelse, som i bedste ODF stil bringer OpenXML spec’en ned på 2 sætninger:

”OpenXML specifikationen samlet af René Løhde:
Læs venligst - ECMA 376 - http://www.ecma-international.org/publications/standards/Ecma-376.htm

Michael J,

Du har glemt spørgsmålet! :-) ... men jeg tolker det som at du spørger om der kan opstå en situation hvor Microsoft laver en ny funktionalitet i Office, som efterfølgende gøres til en del af standarden og som Microsoft derfor har en konkurrence fordel på i fht andre.
Svaret er: ja, det kunne ske! Men det kunne også være IBM, Sun, Novell, KMD osv.... som kom med den nye funktionalitet fordi det ikke er Microsoft, som har kontrol over OpenXML det er en standardiseringsorganisation - ECMA.

Peter,

Teori – Der er et innovativt bootstrap problem hvis man ikke kan lave ny software med mindre der er standard for alle funktionaliteter – hvilket også ODF lider under.

Angående ISO – der står ingen steder skrevet i B103 formulering eller implementationsplan (eller for den sagsskyld i nogen af de høringssvar jeg har læst) at en standard kun er en standard, hvis denne er ratificeret af ISO.

Praktik – en standardformat fortolker skal være gratis er et sympatisk synspunkt, men ikke et krav i B103 sammenhæng. Jeg kan heller ikke se hvorfor det skulle være det.

Angående ”konkurence og valgfrihed” – så mangler supplering af ordene ”interoperabilitet” og ”forretningsunderstøttende” i den sætning – så derfor OGSÅ OpenXML.

Jørgen,

Hvorvidt det er rigtigt eller forkert at bruge lobbyister til at fremme forretning tør jeg ikke gå i en principiel snak om, men jeg har læst ordlyden i den tekst, som Microsoft i flg. den refererede side eftersigende har ønsket fjernet. Det kan jeg ikke se noget forkert i og da slet ikke når der nu har sneget sig en administrativ fejl ind!

...og igen – OpenXML har vel vist at der er en konsekvens i intentionerne og at det er gennemskueligt hvad Microsoft gør på dette område jvf. historikken.

Poul-Henning Kamp

Rene skriver:

Hvis du virkelig mener at side antallet har så stor betydning – så tillad mig en øvelse, som i bedste ODF stil bringer OpenXML spec’en ned på 2 sætninger:

”OpenXML specifikationen samlet af René Løhde:
Læs venligst - ECMA 376 - http://www.ecma-international.org/publications/standards/Ecma-376.htm

citat slut.

Rene, det er den slags der i Holbergs skuespil resulterer i replikken "Er han dum ?"

Nej, du har ikke "i bedste odf stil" nedbragt noget som helst, du har blot afsløret dig selv om værende halvsmart og overfladisk.

Fidusen ved at GENbruge SVG er at man kan GENbruge kode, både før og efter sin ODF implementering.

Jeg noterer mig igen, at dialog med en betalt spin-medarbejder er som at diskutere med en telefonsvarer: hverken produktivt eller tilfredsstillende.

Men ja, jeg synes du skal forsøge at finde ud af hvorfor Microsoft ikke brugte SVG i OOXML, jeg er sikker på at der kommer en fantastiske forklaring som kun har den ene mangel at den ikke er sand.

Microsoft er fundamentalt imod åbne standarder, vi har set det igen og igen. Fra IP protokollen, som Microsoft ikke ville bruge for de ville lave deres eget Internet (MSN er eneste overlevende) over NFSv4 (som ville have fravristet Microsoft servermonopolet) til ODF.

Der er en grund til at EUs antimonopol folk kæmper så hårdt for at få brækket Microsofts tekniske konkurrenceforhindringer op og deres protokoller frem i lyset: De bliver brugt til markedsmisbrug.

Microsoft har ikke noget legitimt krav på fair behanding når det kommer til standarder, for de har aldrig selv behandlet standardisering fair.

Poul-Henning

Jesper Lund Stocholm

> Fidusen ved at GENbruge SVG er at man kan
> GENbruge kode, både før og efter sin ODF
> implementering.

Men er der nogen, der har modsagt dig der? Det jeg (og jeg kan i sagens natur kun tale for mig selv) forsøger at få dig til at indse er, at argumentet med 6000 vs. 600 ikke er et godt argument i sig selv - det skal kvalificeres for at give mening. Du undlod i øvrigt behændigt at svare mig på mit tidligere indlæg, hvor du spurgte, om jeg havde prøvet at implementere en standard på 6000 sider. Når du bliver ved med at tæske på den gamle hest, så fremstår du som et hysterisk barn, der er løbet tør for andre argumenter end "Fordi!", og med de kompetencer jeg i øvrigt tiltror dig, så kan jeg ikke hitte ud af, hvorfor du ikke kan komme med lidt mere intelligente indspark i debatten.

PS: Jeg læste i dag, at der i OOXML er 160 sider med specifikation af regnearksformler. I ODF er der én side. Hvad siger det dig om kvaliteten på dette område i de to standarder?

René Løhde

Poul-Henning,

Er det ikke også overfladisk at blive ved med at fremføre at ODF fylder 600 sider og OpenXML fylder 6000 sider? At lade det være et afsæt for at tale EU retssag og belære om genbrug?

...og jeg er da helt enig i dine SVG genbrugsbetragtninger.

Så lad os være "dybe" og konstruktive - jeg undersøger hvorfor der ikke er SVG i OpenXML set fra et Microsoft synspunkt (NB! Der er SVG implementeret i Microsoft Office - så umiddelbart ville det være GENbrugssmart at bruge SVG i OpenXML for Microsoft!) og du kan prøve at imødekomme "den ene mangel at den ikke er sand" ved at få min "fantastiske forklaring" valideret hos et af de andre medlemmer i ECMA 376.

Poul-Henning Kamp

Hånden op, hvem her har nogensinde læst et værk på 6000 sider ?

6000 sider kan ikke udgives som en bog.

6000 sider kan ikke tages med på ferie.

6000 sider kan ikke tages med i toget.

6000 sider kan ikke være på skrivebordet.

Hvem tror seriøst på at nogen kan implementere en standard på 6000 sider korrekt ?

Nej vel ?

Lur mig om ikke Microsoft har gennemskuet, at jo mere omfangsrig OOXML er, jo mindre chancer har konkurrenterne.

Her er et citat fra den Microsoft godkendte datalog der skulle godkende Microsofts protokoldokumentation i forbindelse med EUs monopoldom:

Barrett described Microsoft's instructions as "totally unusable," and said the software giant never defined terms such as "context handles" and "network objects." Barrett, who was selected from a list of consultants approved by Microsoft, also cited a lack of an index, illustrations, and proper headings in the documentation, and also questions why several hundred pages were devoted to handling computer errors without ever describing how the errors occur in the first place.

Er det ikke påfaldende at Microsofts højt selvberømmede afdeling for dokumentation laver totalt kuk i den, hvergang det er noget konkurrenterne skal kunne bruge ?

Kære Rene og Jesper,

I er ikke en af dem der nogensinde skal læse OOXML fra ende til anden, adskellige gange, for at sikre at jeres produkt overholder standarden.

Derfor kan I sagtens bagatelisere de 5400 ekstra som en masse stakler bliver nødt til at bane sig vej igennem, hvis M$ får manipuleret OOXML igennem.

Men sælgere og marketingfolk har kun bistromatisk forbindelse med de virkelige omkostninger og besværligheder i EDB projekter og derfor har jeres mening på dette punkt ingen vægt eller værdi.

I kan vende tilbage til emnet når I har læst hele OOXML.

Poul-Henning

Simon Grønnegaard

Rene:
Ecma er en medlemsbaseret organisation, hvor det ikke er muligt som enkelt mand at deltage i processen modsat OASIS. Derfor er den ikke åben som det er foreslået i B103.

Hvilken anden applikation har lavet en 100% implementering af EOOXML?

Jesper Lund Stocholm

> I er ikke en af dem der nogensinde skal læse OOXML
> fra ende til anden, adskellige gange, for at sikre
> at jeres produkt overholder standarden.

Måske ikke, det er svært at spå om fremtiden - men det kommer du nok heller ikke til. Til gengæld er jeg sikker på, at firmaer som IBM, Google og Sun - ja vel også Novell eller Apple - kommer til det, og det kan også være, at Leif og OpenOffice.org-drengene kommer til det. Jeg er helt sikker på, at disse firmaer ikke har problemer med at implementere det.

Det virker på mig som om, at din præmis for "acceptabel standardstørrelse" er, at den kan læses på stranden på ferien eller over en lang weekend, og den præmis er jeg ganske enkelt ikke enig i. Jeg er heller ikke enig i, at en standard skal kunne læses "af dig og mig" for at kunne accepteres. Jeg faldt her til morgen over standarden for AES [0], der jo blev godkendt som symmetrisk krypteringsstandard i USA for nogle år siden som afløser for DES. Jeg kender ikke til dine kompetencer indenfor kryptografi, men jeg har læst "lidt" om det på DTU - konkret nærmest boet på Matematisk Institut samt også skrevet speciale og i sin tid bachelorafhandling om kryptering og digitale signaturer. Jeg vil tro, at omkring en trejdedel af mine fagpoint på DTU er taget på matematisk institut i fag direkte omhandlende kryptografi. Jeg er dog helt sikker på, at jeg skulle bruge lang tid på at gennemlæse standarden og samtidig forstå den - og jeg er også sikker på, at AES ikke er noget, som man så blot efterfølgende sætter sig til at implementere ... uden huller.

Standarden er på ca. 50 sider.

Men at sige, at blot fordi jeg (og især andre med kryptografiske kompetencer) ikke kan læse den igennem på vej i bussen på arbejde og implementere den inden frokost, er ikke et godt argument for, at standarden er ubrugelig. Det vigtige for mig er, at det /muligt/ at implementere det på baggrund af spec. De firmaer, der har behov for at implementere den fulde spec for OOXML - og også ODF + refererede standarder - skal nok komme efter det. Vi andre kommer sandsynligvis til primært at anvende begge standarder som opslagsværker, når vi skal danne eller læse dokumenterne vi modtager.

> en masse stakler

?

Jeg er sikker på, at de får løn for deres arbejde.

[0] http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

Jesper Lund Stocholm

> Ecma er en medlemsbaseret organisation, hvor det
> ikke er muligt som enkelt mand at deltage i
> processen modsat OASIS. Derfor er den ikke åben
> som det er foreslået i B103.

Der står ikke noget i B103 om at enkeltpersoner skal kunne deltage i arbejdet [0] - til gengæld står der, at arbejdet skal foregå i en åben proces. Så vidt jeg ved, så er processen forvedtagelse i ECMA ikke offentlig som i OASIS, så det er måske snarere derfor, at den ikke skulle kunne opfylde kriterierne. Vær dog opmærksom på, at kravene om overholdelse af teserne fra aabenstandard.dk ikke er indskrevet i selve beslutningsforslaget, men "kun" i bemærkningerne til det. Derfor er de primært at regne for hensigtserklæringer samt uddybelser til selve beslutningsforslaget (jurister, ret mig endelig, hvis jeg tager fejl).

Jeg synes dog, at du tager det lidt ud af kontekst, men hvis vi et øjeblik lader det ligge, så mener du vel også, at ODF diskvalificeres i punkt 2, da Sun ejer patenter [1], der dækker dele af ODF?

... og nu har vi pludselig ikke nogen standarder at vælge imellem ...

[0] http://www.ft.dk/Samling/20051/beslutningsforslag/B103/som_fremsat.htm

[1] http://xml.coverpages.org/ni2005-10-04-a.html#commentary

Jesper Lund Stocholm

I øvrigt:

> Men sælgere og marketingfolk har kun bistromatisk
> forbindelse med de virkelige omkostninger og
> besværligheder i EDB projekter og derfor har jeres
> mening på dette punkt ingen vægt eller værdi.

Mener du, at jeg falder i kategorien "sælgere" eller i kategorien "marketingfolk"?

Pas nu på, Poul Henning, at glastårnet ikke bliver for højt.

René Løhde

Poul-Henning,

”... som at diskutere med en telefonsvarer: hverken produktivt eller tilfredsstillende” - du mener altså gentagelser af det samme og det samme, igen og igen, uanset hvor mange gange man ringer op!?

Jeg kommer ikke til at læse alle 6000 sider, jeg kan nøjes med del 3 for det software jeg har skrevet og kommer til at skrive. Så tak for indsatsen – ses i en anden tråd!

Simon,

Som jeg læser ECMA’s medlemskaber, så har du ret i at privatpersoner ikke kan optages som medlem, mens at du og jeg - som f.eks en forening – godt kan blive medlem. Du har også ret i at du ikke behøver være en del af en forening/virksomhed for at blive medlem i OASIS.

Den kritik jeg har fulgt på ECMA omkring åbenhed har ikke været på medlemsoptagelsen, men på at man ikke kan følge korrespondence medlemmerne i mellem (Som jeg kan se Jesper LS også er inde på). Der er ikke specificeret noget omkring krav til medlemsoptagelsesbetingelser i B103, som gør en standardsorganisation bedre end en anden.

Angående 100%? Det ved jeg ikke!

Jesper Lund Stocholm

> Angående 100%? Det ved jeg ikke!

Jeg er heller ikke klar over, om der er andre, der har implementeret 100% af OOXML end Microsoft - men jeg synes faktisk at det er mere interessant at bore lidt i, /hvorfor/ spørgsmålet i det hele er relevant. Jeg er sådan set enig i, at der /SKAL/ være andre implementeringer af OOXML end den i MS-Office. Det virker bare lidt som om, at der i pro-ODF verdenen er en opfattelse af, at bare man bruger ODF, så er verden ren og hvid, og alle dokumenter kan læses af alle implementeringer. Men jeg faldt over en ODF-implementerings-oversigt i går [0], der viser, at man bestemt ikke kan være sikker på, at et ODF-dokument lavet i KOffice kan åbnes uden problemer i OpenOffice.org [1]. Faktisk ser det snarere ud til, at det er mere undtagelsen end reglen, at det kan lade sig gøre. Der står desværre ikke noget på siden om datoen for testen - er der nogen af jer, der kender noget til, hvordan billedet ser ud i dag?

[0] http://testsuite.opendocumentfellowship.org/
[1] Leif, ved du om der er overvejelser om at ændre navnet på OpenOffice.org?

Finn Sørensen

René > Kudos for at du overhovedet tør tage debatten op herinde, du er godtnok i mindretal men håndterer det på bedste beskub må jeg sige. Og tak for svarene omkring bl.a. OOXML på SF, det var også et projekt jeg ikke kendte til.

Overordnet set er min største bekymring ift. at bruge 2 standarder ganske enkelt at det ER 2 standarder - interoperabiliteten vil altid blive et emne i praksis, uanset intentioner og værktøjer, især for mindre erfarne brugere. Hvad debatten i denne og tilsvarende artikler jo også klart er et udtryk for, selvom der går en del religion i det også. Jeg ville såmænd ikke være så dårligt tilfreds hvis det blev resultatet, og det kunne det meget vel blive - jeg ville egentlig kun blive skuffet hvis det blev OOXML alene der stod som standarden, da jeg føler at man ville underlægge sig en enkelt leverandør (nok verdens største, men alligevel).

Jeg er unægteligt også selv lidt hellig på visse områder, f.eks. irriterer det mig grænseløst at jeg - for at kunne have Odenses busplan med mig på min (Win-baserede) PocketPC - er tvangsindlagt til at afsætte 25% af enhedens hukommelse til en PDF-reader som jeg sådan set ikke har andet at bruge til - alt andet har jeg i andre formater. Og skiftede jeg styresystemet ud, ville jeg sandsynligvis end ikke /kunne/ læse den pågældende fil, da den ikke er i et specielt kompatibelt format. Men det er en fortsat debat jeg bl.a. har med Odense Kommune, og unægteligt også et spørgsmål om min accept af brug af dokumenttyper ift. kommunens opfattelse af deres public-service forpligtelser.

Jesper og Poul-Henning > Jeg synes lidt at I tærsker langhalm på nogle emner her i en ellers rigtigt god debat med mange synspunkter - den slags spidsfindigheder hører vist mere til i et egentligt debatforum hvor I kan gå endnu mere i dybden, ikke så meget i debatkommentarerne til en artikel. Men det er vi sikkert heller ikke enige om, og det er ikke mig der lægger den redaktionelle linje for Version2, så det må vel være op til redaktørerne. Blot et venskabeligt råd - undgå at udvande debatten hér hvor man nok gerne skal have så mange læsere med hele vejen igennem som muligt, heriblandt da forhåbentligt også nogle af de politikere og beslutningstagere der er involveret i denne proces.

Mht. de 100%, er det vist et luftkastel - der er intet der er helt 100% indenfor IT i praksis. Og realistisk set kan både MS Office og OpenOffice jo altså læse hinandens dokumenter i tilstrækkelig grad til at der ikke går noget væsentligt tabt - og min klare fornemmelse er trods alt at begge parter søger at gøre tingene så inter-kompatible som muligt, til glæde for alle. Der er måske et stykke til de 100% - men vi er sørme da på vej i den rigtige retning, uanset synspunkter i øvrigt.

Jesper Lund Stocholm

> Jesper og Poul-Henning > Jeg synes lidt at I
> tærsker langhalm på nogle emner her i en ellers
> rigtigt god debat med mange synspunkter

Jeg er helt enig - jeg ville også ønske, at vi ikke skulle tale sidetal mere.

Når jeg konsekvent kommenterer Poul-Hennings argumenter med 600vs6000, så skyldes det, at Poul-Henning desværre af nogen opfattes som "sandhedsvidne" i denne debat og hans argumenter har en tendens til via andre debattører at sprede sig til andre fora også. Derfor ser jeg mig nærmest nødsaget til at svare på dem, når de "blobber op". Jeg vil nemlig - som du selv peger på - nødigt risikere, at en politiker læser det uimodsagte argument om 600vs6000 og bruger det til at stemme for anvendelse af kun ODF i den danske offentlige sektor.

Thomas Kjeldsen

Rene> "Jeg undersøger hvorfor der ikke er SVG i OpenXML set fra et Microsoft synspunkt (NB! Der er SVG implementeret i Microsoft Office - så umiddelbart ville det være GENbrugssmart at bruge SVG i OpenXML for Microsoft!)"

Jeg har fulgt med i debatten her de seneste par dage, og jeg glæder mig til at høre en forklaring på ovenstående.

Det undrer mig - ligesom PHK - at OOXML spec'en er så stor. Den famøse dato-repræsentation kunne vel fx være beskrevet i en selvstændig spec.

Rene: har du lyst til og mulighed for at undersøge hvorfor det ikke er tilfældet?

Den eneste begrundelse jeg har hørt er et modargument ala "ODF på 600 sider henviser jo til masser andre specs og når de skal tælles med bliver det ialt til mange flere sider!"

Som udenforstående er det svært ikke at drage en parallel til en konkret implementation, og oversætter man ovenstående bliver det til noget ala: Hvorfor strukturere og modularisere når det hele kan inlines i een fil - det fylder jo det samme, vel nærmest lidt mindre!

Det argument var muligvis gangbart i forrige århundrede, men det holder altså ikke i dag :-)

Jesper Lund Stocholm

> Som udenforstående er det svært ikke at drage en
> parallel til en konkret implementation, og
> oversætter man ovenstående bliver det til noget
> ala: Hvorfor strukturere og modularisere når det
> hele kan inlines i een fil - det fylder jo det
> samme, vel nærmest lidt mindre!

Selvfølgelig er partitionering og modularisering vigtig, men det er ikke det samme som at det giver mening at tælle sider som Poul-Henning gør.

Jeg har ikke tidligere tænkt over din analogi, som faktisk er lidt skæg :o) ... og den giver også fint mening. Det er jo nemlig et fint implementeringsmæssig rationale i at udskille funktionalitet i flere filer og moduler og klasser, så disse kan genbruges.

Lad os derfor antage, at du/I har lavet en kæmpe desktop-applikation til styring og overvågning af en eller anden proces. Alt i alt er den på flere tusinde liniers kode - alt perfekt opdelt i klasser med korrekt nedarvning, polymorfi + alle de andre buzz-ord indenfor godt OO-design. Når Poul-Henning insisterer på at tælle, som han gør, så svarer det til at han siger, at kildekoden for den omfangsrige applikation er på 5 linier, da startklassen kun indeholder koden

[STAThread]
static void Main()
{
Application.Run(new StartAppClass());
}

(.Net 1.1)

:o)

Poul-Henning Kamp

Hvis Danmark beslutter sig for ODF, så makker Microsoft ret.

Det kan godt være at det tager lidt tid, men de makker ret, før eller siden, for den offentlige administration i Danmark er for stor en kunde til at de bare opgiver den.

Men efter al sandsynlighed bliver det ikke Danmark der bliver foregangslandet, det bliver sikkert Norge, Belgien eller et andet fremsynet land.

Poul-Henning

Poul-Henning Kamp

Jesper,

At jeg vitterligt er sandhedsvidne i denne debat skyldes at jeg, tilsyneladedne som den eneste, har real-life erfaring med XXL størrelse foreskrivende dokumenter.

Når SVG er sin egen standard, så er dens grænser veldefinerede og ligeledes er grænserne veldefinerede imellem ODF der refererer til SVG.

Selvom OOXML beskriver sit hjemmestrikkede grafikformat på siderne 2100-2600, så vil man stadig være tvunget til at gennetrawle de andre 5500 sider for at finde ud af om der er noget der, der påvirker eller flytter grænserne imellem grafikdelen og resten.

Selvom OOXML teknisk måtte være bedre end ODF, noget jeg ikke ser nogen håndgribelige beviser for, så er den en ringere standard alene på grund af størrelsen og den manglende modularisering.

Og ja, jeg ville også have brokket mig over størrelsen hvis det havde været omvendt og ODF havde været på 6000.

Hvis ikke et foreskrivende dokument kan være i et bind, så er der aldrig nogen der får læst sig hele vejen igennem det og dermed aldrig nogen der får et så intimt kendskab til indholdet at det kan bruges til noget.

Det er derfor vi har så mange store EDB fiaskoer: Når der ikke er en eneste person der er bekendt med alle projektets foreskrifter, så er det næsten per automatik dødsdømt.

Jeg er helt sikker på, at en kompetent skribent kan sammenskrive OOXML til kun det halve sidetal, ved at tænke sig om og ved at strukturere ting bedre.

At Microsoft ikke har gjort det er naturligt: der er ingen grund til at give konkurrenterne noget ved dørene.

OOXML, som dokument beset, er simpelthen ikke skrevet for at man skal kunne arbejde med det.

At ECMA skulle have givet standarden den detailopmærksomhed en standard har brug for kan udelukkes alene ved at kigge på den tid de har brugt.

At forlange at ISOs medlemslande skal kunne nå at gå den igennem på nogle få måneder er ligeså uvederhæftigt.

I modsætning hertil står ODF, der er skrevet af en gruppe folk der skal bruge det, som dokument og derfor har de naturligvis arbejdet på at holde dokumentet læseligt og i en størrelse der er til at håndtere.

Det offentlige bør under ingen omstændigheder adoptere en standard der giver en markedsdominerende spiller en enorm fordel, hverken via patenter, installeret base eller omfang.

Længere er den historie sådan set ikke.

Det perfekte svar til Microsoft er derfor:

Vi synes OOXML lyder spændende. Men I bliver nødt til at skrive den ned på under 1000 sider og/eller del den op i nogle fornuftige understandarder, ellers gider vi ikke spilde tid på det.

Poul-Henning

Thomas Kjeldsen

Jesper> "så svarer det til (...) at kildekoden for den omfangsrige applikation er på 5 linier"

Næh.

Det der er interessant er det antal linjer som man selv er nødt til at skrive.

Hvis man kan hive et dato-bibliotek (stadig blot et eksempel) ned fra hylden hos sin favorit-leverandør, så har man udliciteret den opgave - og derved sparer man et antal linjer kode.

Jo flere ting man kan gøre det ved, jo bedre.

Jørgen Ramskov

Jeg synes faktisk den blog der linkes til er mere interessant: http://blog.janik.cz/archives/2007/05/19/T20_32_07/

Citat:

=== Klip ===
I have read approx. 200 pages of the specification and I decided to stop, because it is dangerous. The ideas presented in various parts of the specification (like two ways to represent the date - one of them representing dates between 1900 and 20000 and another one to represent dates between 1904 and 20000 where the second one is a complete subset of the first one!) are dangerous to the mental health of the reader. The innovative method of storing the language code (e.g. the decimal integer 58380 into two digit hexadecimal number) is also worth a world-wide patent...

I simply can't believe that developers and or TC45 members from Apple, Barclays Capital, BP, The British Library, Essilor, Intel, Microsoft, NextPage, Novell, Statoil, Toshiba, and the United States Library of Congress actually read the final document. I can't believe it. If I ever write such document, I surely won't sign it by my name. Why?
=== Klip ===

Jeg må sige at jeg er enig. Jeg kan forstår hvad feks. ovenstående eksempler laver i en standard og det er sikkert ikke de eneste.

OOXML ser ud til at blive presset igennem så hurtigt som muligt (langt hurtigere end ODF, der samtidigt er en meget mindre specifikation!) og det virker som om der burde blive brugt meget mere tid på at gå specifikationen igennem.

Rene, du skriver:
=== Klip ===
OpenXML blev ikke ”smækket” hurtigt sammen – der har været under udvikling igennem 10 år og forgængeren blev ”åbnet” i 2003.
=== Klip ===

10 år er lang tid, XML 1.0 standarden eksisterede ikke før 1998, men det jeg synes er ærgeligt (men desværre ikke overraskende) er at Microsoft så må have ventet i ~8 år før de valgte at sende den til en standardiseringsorganisation. Det er helt tydeligt at Microsoft kun har valgt at gøre det fordi de er blevet presset af ODF til det. Nu har de så til gengæld super travlt med at få det gjort til en standard.

Jens Kolberg

> Men jeg faldt over en ODF-implementerings-oversigt i går [0],
> der viser, at man bestemt ikke kan være sikker på, at et ODF-
> dokument lavet i KOffice kan åbnes uden problemer i
> OpenOffice.org [1]. Faktisk ser det snarere ud til, at det er mere
> undtagelsen end reglen, at det kan lade sig gøre. Der står
> desværre ikke noget på siden om datoen for testen - er der nogen
> af jer, der kender noget til, hvordan billedet ser ud i dag?

http://testsuite.opendocumentfellowship.org/ kan du se at det er OpenOffice 2.0.1 og KOffice 1.5.2 der sammenlignes.

De nuværende versioner er OpenOffice 2.2.0 og KOffice 1.6.2. Kompatibiliteten er nok endnu bedre nu...

Det kunne være interessant at den tilsvarende kompatilitetsliste for den nyeste version af Word vs. OOXML. Jeg har ikke set noget bevis for at MS-Word faktisk implementerer hele OOXML.

Jens Kolberg

Finn Sørensen skrev:
> Og realistisk set kan både MS Office og OpenOffice jo altså læse
> hinandens dokumenter i tilstrækkelig grad til at der ikke går
> noget væsentligt tabt - og min klare fornemmelse er trods alt at
> begge parter søger at gøre tingene så inter-kompatible som
> muligt, til glæde for alle. Der er måske et stykke til de 100% -
> men vi er sørme da på vej i den rigtige retning, uanset
> synspunkter i øvrigt.

Her tager du helt fejl. Der er udelukkende OpenOffice's fortjeneste og intensive reverse-engineering, at de kan læse og skrive Word dokumenter nogenlunde. Der har INGEN hjælp været fra MS's side, til at dokumentere det gamle word-format, så andre kan implementere det.

Det er først med OOXML formatet at der er sket en forbedring, men hovedparten af verdens Word dokumenter ligger stadigvæk i det gamle binære format... OOXML er trods alt meget nyt.

Og det er først meget fornyligt at MS (nødtvunget, på grund af det pres der er), har taget initiative til nogle meget halvhjertede projekter, der kan konverttere ml. OOXML og ODF.

Jens Kolberg

Jesper Lund Stocholm skrev:
> Lad os derfor antage, at du/I har lavet en kæmpe desktop-
> applikation til styring og overvågning af en eller anden proces.
> Alt i alt er den på flere tusinde liniers kode - alt perfekt opdelt i
> klasser med korrekt nedarvning, polymorfi + alle de andre buzz-
> ord indenfor godt OO-design. Når Poul-Henning insisterer på at
> tælle, som han gør, så svarer det til at han siger, at kildekoden
> for den omfangsrige applikation er på 5 linier, da startklassen
> kun indeholder koden

Sikke noget sludder.

Hele ideen med at lave fælles, åbne standarder er jo at modularisere og genbruge.

Så behøver man kun lave et modul (klasse) der kan håndtere datoer, i alle de applikationer, der bruger datoer.

Eller et modul (klasse) der håndterer vektorgrafik, osv.

Hvis man vil gøre det svært for ens konkurrenter, så laver man sine egne standarder på alle områder. Eks.:

Vi vil lave et office format, der skal bruges fonte, dokument formatering, dato formatering vektorgrafik, bitmapgrafik, matematik opsætning, etc. Lad os lave vores egne standarder på alle disse områder, så kan vi holder konkurrenterne i gang hele tiden.

Ja, i teorien kan det implementeres, men det er os der hele tiden har initiativet.

Vi udvidder bare "standarden" eller opfinder en ny: PDF - nej, det skal være XPS. SVG - nej det skal være WMF. JPG - nej det skal være HD-Photo. MPG - nej det skal være WMV. MP3 - nej det skal være WMA. JVM - nej det skal være CLR. NFS - nej det skal være SMB. osv. osv.

Med den historik er det ikke så underligt at mange er skeptiske overfor MS standarder.

"Embrace, extend and extinguish" er Microsofts strategi, og OOXML er ikke anderledes. Se http://en.wikipedia.org/wiki/Embrace_and_extend

Dennis Krøger

Selv om jeg er enig med det meste, er den sidste del en sideløbende MS strategi, ikke den samme...

Den går ud på at tage noget godt, udvide det eller ændre det med sine egne ikke-kompatible extensions, og gøre standarden til sin egen, eller bare gøre den ubrugeligt så ens eget bliver brugt istedet. Eksempler er WWW, Kerberos, og SMB (Nej, SMB er ikke opfundet af MS).

Det du beskriver er istedet MS' almindelige Not-Invented-Here filosofi, hvilket de så bestemt ikke er ene om, der er for eksempel ganske mange som ikke vil røre ting udelukkende fordi MS står bag (Hvilket dog ofte mere kunne tolkes som en slags brændt-barn-skyr-ilden reaktion, end rendyrket NIH).

JLS har til gengæld en eller anden mærkelig opfattelse af at man ikke får noget ud af genbruget, på baggrund af at et par enkelte firmaer kunne finde på at kræve at de mange allerede implementerede og gennemprøvede libraries (både Open Source og kommercielle, Jesper bragte for some reason OSS ind i billedet) ikke må benyttes...

Er det ikke lidt som at holde på dampmotorer, fordi der måske er 4 mennesker der vil nægte at bruge eksplosionsmotorer (Nu vi er igang med at kaste analogier frem og tilbage)?

Jesper Lund Stocholm

> Hvis man kan hive et dato-bibliotek (stadig blot
> et eksempel) ned fra hylden hos sin
> favorit-leverandør, så har man udliciteret den
> opgave - og derved sparer man et antal linjer
> kode.
>
> Jo flere ting man kan gøre det ved, jo bedre.

Jeps - her er jeg helt enig. Men kan du forklare mig, hvorfor det ikke skulle være muligt for dig at implementere fx VML og sælge det til dine kunder? At det ikke er en "standard i sig selv" betyder jo ikke, at der ikke er nogen, der kan tage siderne 2100-2600 (Poul-Henninngs tal) og implementere deres egen VML-komponent, som du så har mulighed for at købe.

Jesper Lund Stocholm

> JLS har til gengæld en eller anden mærkelig
> opfattelse af at man ikke får noget ud af
> genbruget

Øehm - det har jeg aldrig sagt.

> på baggrund af at et par enkelte
> firmaer kunne finde på at kræve at de mange
> allerede implementerede og gennemprøvede libraries
> (både Open Source og kommercielle, Jesper bragte
> for some reason OSS ind i billedet) ikke må
> benyttes...

Jeg ved ikke, om det blot drejer sig om et par enkelte firmaer - jeg refererer blot til den virkelighed, som jeg lever i til dagligt. Det er ikke en usædvanlig ting, at kunder er mildest talt vrangvillige og skeptiske overfor at anvende 3-parts produkter/komponenter og i særdeleshed OSS-produkter. Det er naturligvis ikke noget man kan bebrejde OSS men derimod uoplyste kunder. Det er blot desværre set, at vi ikke har kunnet overbevise en kunde om, at vi skulle anvende komponent X til job Y ... og er endt med selv at skulle implementere det.

Men jeg mangler stadig svar på: Hvad skulle afholde virksomhed X i at implementere VML og give "os andre" mulighed for at anvende den i vores applikationer?

... og som en lille slutnote: VML er ikke det anbefalede format til grafik i OOXML. Det anbefalede format er DrawingML. VML er medtaget pga bagudkompatibilitet.

og endelig mangler jeg også svar på: Hvorfor er det principielt vigtigere for jer, at spec for grafikformatet ikke er udskilt i en selvstændig standard end at ODF ikke indeholder nogen information om format for formler?

Jesper Lund Stocholm

Poul-Henning,

> Selvom OOXML beskriver sit hjemmestrikkede
> grafikformat på siderne 2100-2600, så vil man
> stadig være tvunget til at gennetrawle de andre
> 5500 sider for at finde ud af om der er noget der,
> der påvirker eller flytter grænserne imellem
> grafikdelen og resten.

Nej - det behøver du faktisk ikke. I spec er det klart defineret (Part4, sec. 1.4+1.5) hvilke dele af spec, der er relevante for netop fx DrawingML. (er siderne for VML i øvrigt ikke snarere 4343-4960?, kapitel 6).

Angående generelle diskussioner om længden af OOXML, så faldt jeg over denne kommentar [0]

"I have obviously not read the entire specification, and am biased towards what I have seen in the spreadsheet angle. But considering that it is impossible to implement a spreadsheet program based on ODF, am convinced that the analysis done by those opposing OOXML is incredibly shallow, the burden is on them to prove that ODF is "enough" to implement from scratch alternative applications."

Kritik af størrelse, anvendelse og tekniske detaljer i OOXML er naturligvis på sin plads, men som jeg tidligere har skrevet, så mangler jeg selvrefleksion over ODF-formatet fra "jeres" side. Hvis OOXML skal afvises pga sammensætningen af standardokumentet og dets størrelse og mangel på anvendelse af eksisterende standarder, hvorfor skal ODF så ikke også afvises pga konkrete problemer i_selve_formatet og manglende essentielle dele af spec?

:o)

[0] http://tirania.org/blog/archive/2007/Jan-30.html

Jesper Lund Stocholm

Jørgen,

> OOXML ser ud til at blive presset igennem så
> hurtigt som muligt (langt hurtigere end ODF, der
> samtidigt er en meget mindre specifikation!) og
> det virker som om der burde blive brugt meget mere
> tid på at gå specifikationen igennem.

Det er muligt, at der er brugt mere tid på ODF i ISO end OOXML i ECMA (jeg har ikke tallene lige her), men ODF er stadig mangelfuld og bærer også præg af at være skubbet for hurtigt på markedet.

http://notes2self.net/archive/2006/07/12/446.aspx

Forklar mig så lige, hvorfor du ikke kritiserer ODF-støtterne for at tænke mere på "first-to-market" end på en brugbar standard?

Jørgen Ramskov

Jesper Lund Stocholm: Jeg tænker ikke kun på ISO, jeg tænker i høj grad også på OASIS hvor meget af benarbejdet så vidt jeg ved foregår.

Det er helt sikkert ikke optimalt at ODF ikke har formularer. Det arbejdes der så på at ændre, så hvis jeg forstår det korrekt, så vil næste version (1.3?) inkludere det.
Om den ligefrem er blevet skubbet for hurtigt frem, det er jeg mere tvivlende overfor. Efter hvad jeg ved så blev der brugt rimeligt lang tid i OASIS på at lave ODF 1.0 specifikationen med input fra ret mange "fronter". Hvis det er tilfældet, så er det selvfølgeligt kritisabelt.

ODF er helt sikkert ikke perfekt og jeg har muligvis heller ikke kompetencen til at gå i dybden med specifikationerne (jeg har egentligt heller ikke lysten), men for mig at se så er der meget gode grunde til at vælge ODF frem for OOXML. Grundene har været fremme før, men et er at det vil fremme konkurrencen. Lige nu har vi et monopol på området, hvis OOXML vælges så vil MS helt sikkert beholde deres monopol. Jeg mener også det er helt forkert at basere det på økonomien. Bla. den seneste rapport fra Rambøll hvor det påståes at det vil koste 180 millioner at implementere ODF. Det er håndører i det store billede og bør ikke have nogen indflydelse på beslutningen.

René Løhde

Jesper LS,

Enig i dit syn på de 100% og jeg kender godt den der test suite – den er interessant – however jeg ville ønske at den var lavet med ISO versionen af ODF.

Finn,

Selv, tak! Din deltagelse er værdsat.
Jeg læser din bekymring og det er rart at komme tilbage på track til intentionerne i den oprindelige blogpost hernede omkring kommentar 75 :-) Jeg er helt enig i alle dine betragtninger om 2 standarder og at en OpenXML only situation ikke er ønskelig. Jeg har altid været modstander af en ”one-to-rule-them-all” politik. Jeg forsøger i indlægget at redegøre for at forskellige teknologier til samme forretningsområde, er reglen mere end det er undtagelsen og at markedet som regel er i stand til at finde løsninger på interoperabilitets problemer. Jeg mener at udelukkelsen af en standard og dermed de tanker og års innovation, som ligger bag, på ingen måde kan gavne nogen, hverken på kort eller længere sigt.

...og ja, – smartphone, pocket pc etc har så meget potentiale, men lider under at alt indhold som skal konsumeres er skrevet til ”en personlig skrivebordscomputer”.

Thomas,

Jeg undersøger ”hvorfor ikke SVG i OpenXML” – skal jeg skrive svar i denne tråd eller lave en ny post? Jeg spørger fordi jeg ikke ved om der er kommentarer med i RSS feed på V2 og der kan godt gå et stykke tid inden jeg finder en afklaring på SVG spørgsmålet.

Angående dato issue - kan du være lidt mere præcis på hvad det er du godt kunne tænke dig undersøgt?

Angående partitionering så er OpenXML spec’en stykket sådan ud at der f.eks allerede nu er en del af XML Paper Specification (XPS), som nu er en åben standard. Dette skyldes at del 1 af OpenXML er beskrivelsen af Open Packaging Convention (OPC), som også bruges i XPS.

Det gælder for OpenXML og ODF at der er forskellige tilgange til partitionering og disse er igen truffet i en design beslutning. Tillad mig at komme med et eksempel som måske kan illustrere hvor forskellen på en partitioneret genbrugsstrategi har vejet højest for ODF. I ODF repræsenteres tabeller typisk som et regneark, et billede eller en samling af billeder. Umiddelbart virker dette fornuftigt – specielt for de som skal skrive software bibliotekerne til brug ved tabeller. I OpenXML er der en tabel repræsentation til tekstbehandling og presentation + at man har de muligheder som er modellen i ODF. I ODF har designerne vurderet at 2 tabel partitioner var nok, mens man i OpenXML har vurderet at 4 var minimum.

Så kan vi diskutere frem og tilbage om hvad der er bedst alt afhængig af kontekst. Som udvikler vil jeg fortrække ODF’s design, mens jeg som arkitekt og slutbruger vil fortrække OpenXML’s version.

Michael,

Hvis du mener at DK er for lille til at have sin egen struktur og presentationsXMLdialekt så tror jeg at du tager fejl. Softwareleverandørerne må i stigende grad stille software til rådighed, som afspejler de lokale forretningsgange og krav.

Jørgen,

Jeg har længere oppe skrevet hvorfor der er det såkaldte dato issue – hvorfor ikke forholde sig til dette i en debat/dialog - istedet for at finde steder på nettet hvor rigtig mange har på peget dette som et stort issue (inkl min 3 i denne tråd).

Kan vi ikke diskutere – om skudårsproblematikken er et issue fordi det ikke skaber interop mellem applikationer, er svært at implementere, at man ikke er opmærksom på problemet (no chance there!) Hvor i består det problematiske i at implementere en fejl, som ikke har nogen praktisk betydning for brugerne og som er i direkte tråd med det erklærede mål for OpenXML om bagudkompabilitet (i dette tilfælde bagudkompabilitet med en fejl skabt i Notes!)?

Angående historik - Da XML var færdig i 1997 (og indstillet til godkendelse!) var det begyndelsen på noget nyt hos Microsoft. Jeg tror ikke at der var mange i Microsoft, som på det tidspunkt tænkte på at om 10 år har vi et fuldt XML baseret format vi standardiserer på. I 1997 var det vigtigste krav til et dokumentformat at det kunne repræsenteres i en fil, som kunne overføres til en floppy-disk.
Evolutionen skete og langsomt blev data og præsentation i dokumentformaterne ”lagt” i XML – startende med metadata. Dette kulminerer i 2001 (!?) da der kommer et ”fuldt” XML format i Excel. I 2002 kommer Word med og i 2003 beslutter Microsoft at åbne dokumentformatet op så alle kan få adgang for de XML teknologier implementeret i Office inkl Excel (SpreadsheetML), Word (WordprocessingML), Infopath (XSN Templates) og Visio (kan jeg ikke huske hvad!). I 2004 lader EU kommissionen Microsoft vide, at man gerne ser WordprocessingML standardiseret – hos en standardiseringsorganisation valgt af Microsoft og at Microsoft og ODF leverandører anstrenger sig for at få interop (http://ec.europa.eu/idabc/en/document/2592/5588). Året efter gøres hele officepakken til XML og dette bliver defaultformat og XML formatet søges standardiseret. Samtidigt starter Microsoft et projekt med interop på ODF til Officepakken, som er i beta nu.

For mig fremstår dette som en logisk og transparent historik.

Jens,

Er det ”halvhjertet” at lave sin udvikling af OSS på Sourceforge?

Tillad mig at forsætte min historik fra svaret til Jørgen. ” Microsoft et projekt med interop på ODF til Officepakken, som er i beta nu”.... dette gøres ved at hyre eksperter fra en række OSS software huse til - i fuld offentlighed og med dokumentation - at implementere ODF i Microsoft Office.

Hvorfor tror du at Microsoft for første gang i firmaets historie laver noget på Sourceforge? – jeg tror det er for at imødekomme den meget forudsigelige kritik om ”embrace, extend and extinguish”, som vil opstå når ODF ikke renderer i Microsoft Office som det f.eks renderer i OpenOffice eller når funktionalitet går tabt. Som det er nu kan du gå ind og kigge på koden og dokumentation og se hvilke issues der er og hvorfor!

Dennis,

Jeg er ikke med – siger du at JLS, Microsoft og undertegnede (de ”4 mennesker”) forsøger at holde noget tilbage i denne disskussion?

Vi slår da alle på tromme for ikke at holde noget tilbage (også det som ikke er opfundet hos Microsoft) i B103 – no ”one-to-rule-them-all”!

Jesper Lund Stocholm

> Jeg tænker ikke kun på ISO, jeg tænker i høj grad
> også på OASIS hvor meget af benarbejdet så vidt
> jeg ved foregår.

Jeps - som jeg forstår det, så vedligeholdes ODF i OASIS-regi og OOXML i ECMA-regi. Mht presset på at få skubbet OOXML hurtigt igennem ISO, så læste jeg, at der var tilknyttet en "ISO-liason" til TC-gruppen for ECMA. Formålet var at vejlede ECMA til, hvordan standarden skulle skrues sammen, så arbejdet med at godkende den som ISO-standard kunne blive mindst muligt.

> Om den ligefrem er blevet skubbet for hurtigt
> frem, det er jeg mere tvivlende overfor. Efter
> hvad jeg ved så blev der brugt rimeligt lang tid
> i OASIS på at lave ODF 1.0 specifikationen med
> input fra ret mange "fronter". Hvis det er
> tilfældet, så er det selvfølgeligt kritisabelt.

I den artikel jeg refererede til er OASIS-TC medlem Gary Edwards citeret for at sige:

"Time is of the essence. Ratification perhaps trumps perfection. At least for the moment. [...] We are very much aware that whatever we leave outside the specification remains open (or not) and exposed to ambiguities and custom implementations, all of which have proved to be so problematic in the past." [0]

Når jeg trækker dette eksempel frem, så er det for at illustrere, at mange af de politiske manøvrer som Microsoft beskyldes for at have, har mere eller mindre identiske ækvivalenter på "jeres" egen side i skaberne af ODF. Diskussionen på OASIS-maillisten er også interessant, fordi det viser, at der på et meget tidligt tidspunkt var bekymring over de applikationsspecifikke udvidelser af ODF samt manglerne mht fx formelbeskrivelse. Dette var vel at mærke ikke fra OOXML-folk, men af de folk, der deltog i større eller mindre grad i udviklingsarbejdet med ODF. De problemer er stadig ikke blevet løst.

Disse problemer er netop kernen i nogle af de forbehold, jeg har overfor ODF. En anden på maillisten formulerer det således:

"Every implementation must reverse engineer all other implementations' namespaces (they're not in the spec, so everyone's free to invent their own private incompatible namespaces). Then, every implementation must implement all the syntax and semantics of all other implementations' namespaces for formulas, if they wish to achive interoperability. And oh, by the way, your
implementation might not implement the namespace for the document you're trying to load, so you may lose all the formulas." I'm sure that's not what was meant, but that's how it reads to me. I hope that helps explain why I think that the current formula information in the OpenOffice specification is grossly inadequate.[...]"

Med dette in mente kan jeg simpelthen ikke forstå, hvorfor I synes, at det er så vigtigt at diskutere, om DrawingML skulle være skilt ud som en seperat standard eller fordele og ulember ved modularisering eller partitionering. Disse ting er vigtige - det er jeg enig i - men vi taler altså om, at ODF ikke har en meningsfuld måde at håndtere formler i regneark på. Er det slet ikke nogen, der kan forestille jer, de problemer dette giver ... eller sætter I kikkerten for det blinde øje?

> Lige nu har vi et monopol på området, hvis OOXML
> vælges så vil MS helt sikkert beholde deres
> monopol

Jeg er ikke sikker på, at du har ret, og jeg synes sådan set ikke, at det er en blå-øjet/naiv opfattelse. Det virker på mig som om, at det i situatoner vil være dyrere at implementere understøttelse (i et eller andet omfang) af OOXML end tilsvarende for ODF. Jeg kunne i hvert fald forestille mig, at jeg i mange tilfælde vil anbefale en kunde at betale for understøttelse af ODF og evt OOXML som tilvalg. Derudover er jeg sikker på, at hvis OOXML godkendes, så vil der inden for et halvt/helt år være understøttelse af OOXML i Novells kontorpakke (de har jo et samarbejde med Microsoft om teknologier), IBMs Lotus-pakke, i Google Docs og derudover har Corel også lovet understøttelse for OOXML. Jeg er også 100% sikker på, at vi vil se understøttelse af OOXML i produkter som OpenOffice.org samt KOffice og andre. Dermed er der altså et helt andet grundlag at presse Microsoft på end vi har nu, hvor Microsoft er de eneste, der kan levere fuld understøttelse af dokumenter dannet af MS-Office.

> Jeg mener også det er helt forkert at basere det
> på økonomien.

Enig - for mig er det også irrelevant

> Bla. den seneste rapport fra Rambøll hvor det
> påståes at det vil koste 180 millioner at
> implementere ODF. Det er håndører i det store
> billede og bør ikke have nogen indflydelse på
> beslutningen.

Præcist :o)

[0] http://lists.oasis-open.org/archives/office-comment/200502/msg00007.html

[1] http://lists.oasis-open.org/archives/office-comment/200502/msg00006.html

Jesper Lund Stocholm

René,

> Jeg undersøger ”hvorfor ikke SVG i OpenXML” – skal
> jeg skrive svar i denne tråd eller lave en ny
> post?

Jeg vil foretrække, at det kommer i et nyt blogindlæg. Forum-interfacet på v2.dk er ikke super optimalt, og dit svar kunne risikere at blive g(l)emt væk.

... jeg glæder mig også til at se svaret :o)

Casper Thomsen

Hej alle - og tak for den meget interessante debat med et højt niveau og en pæn tone.

Ikke for at forplumre en i forvejen lang debat, men dette er den hidtil mest omfattende debattråd, vi har haft på version2.dk siden lanceringen i efteråret.

> Jeg vil foretrække, at det kommer i et nyt
> blogindlæg. Forum-interfacet på v2.dk er ikke
> super optimalt, og dit svar kunne risikere at
> blive g(l)emt væk.

Vi er i gang med en opgradering af vores debatsystem (som også kommer i brug på ing.dk), hvor der blandt andet bliver mulighed for at overvåge tråde vha. mail og RSS. Herudover bliver der bedre mulighed for citat.

Derudover vil jeg selvfølgelig gerne høre deltagerne i en omfattende debattråd som denne, om I ser andre ting, man kunne gøre for at understøtte en brugervenlig og overskuelig debat - også når der går ODF/OOXML i den? :-)

Mvh Casper, Version2

michael rasmussen

1) Nu ved jeg ikke, hvad bedre citat dækker over, men jeg kunne godt tænke mig, at man kunne besvare et indlæg i stedet for at kommentere nederst på listen.
2) Få præsenteret indlæggene i tråde. Afhænger af 1)
3) Mulighed for at få vist kladde af indlæg får afsendelse samt mulighed for at rette i sit indlæg.

/Michael

Dennis Krøger

"Jeg er ikke med – siger du at JLS, Microsoft og undertegnede (de ”4 mennesker”) forsøger at holde noget tilbage i denne disskussion?"

Nej, jeg påpegede bare (gennem en åbenbart elendig analogi :)), at det at et par firmaer (<- de fire mennesker) ville beslutte sig for ikke at benytte allerede udviklede og gennemprøvede komponenter til deres ODF implementering, bestemt ikke betyder at genbruget er spildt (Bortset fra for dem, men det er virkelig deres eget problem).

Hvis de vil skal de have lov til at spilde penge på det, men det er ubrugeligt som argument for noget som helst andet end en fyringsrunde hos dem.

Jesper Lund Stocholm

Diskussionen om modularisering af en standard udsprang jo af Poul-Hennings og min diskussion af "600vs6000". Der er blevet fremsagt som argument, at man ved implementering af ODF ikke behøver at tænke på de 700 sider i fx SVG, da man jo bare kan bruge en af de implementeringer, der allerede /er/ lavet - og i øvrigt at man er idiotisk eller fyringsklar, hvis man vælger at gøre det anderledes. Men så lad os da smide spec for SVG væk - den er jo allerede blevet implementeret af flere forskellige, så vi behøver den jo ikke mere.

Min pointe er, at sådan fungerer verden altså ikke. Der vil naturligvis være behov for løbende at implementere SVG på ny i fremtiden. Når der kommer nye platforme, nye hardware-arkitekturer eller ganske enkelt nye krav til software(s performance), så vil behovet opstå og derfor er det en dåres argument [ for nu at gøre udtrykket lidt mere spiselisgt :o) ] at sige, at man "bare kan bruge en eksisterende implementering og derfor ikke behøver at kigge i spec for SVG". /Derfor/ skal siderne for bla. SVG naturligvis lægges til de 600 for ODF, hvis man insisterer på at tælle sider.

Men som du selv er inde på, så er det jo ikke det samme som at genbruget er spildt. Det er klart, at der er fordele i at have fx SVG, DrawingML, SpreadsheetML eller WordProcessingML lagt ud som selvstændige standarder. Fx er det en fordel for ODF /OG/ SVG, at de kan udvikles parallelt, og det er lidt svært at forestille mig, hvordan det kan ske på samme måde med OOXML og fx PresentationML. Jeg kunne forestille mig, at Microsoft til næste version af OOXML ville søge at standardisere de enkelte markup-languages og dermed skille dem ud som seperate standarder. René, har du evt hørt noget om disse tanker?

Jesper Lund Stocholm

René,

> Jeg er ikke med – siger du at JLS, Microsoft og
> undertegnede (de ”4 mennesker”) forsøger at holde
> noget tilbage i denne disskussion?

Det har været et par pudsige debatdage. Først bliver jeg "slået i hartkorn" med Poul-Henning (indlæg 3149) og nu bliver jeg puttet i boks med Microsoft. Vær venligst opmærksom på, at jeg ikke repræsenterer nogen af disse men "kun lille mig".

:o)

Jørgen Ramskov

"Dermed er der altså et helt andet grundlag at presse Microsoft på end vi har nu, hvor Microsoft er de eneste, der kan levere fuld understøttelse af dokumenter dannet af MS-Office."

Det er vel næppe overraskende? Specielt ikke når formaterne er proprietære.

OOXML indeholder hvis jeg har forstået det korrekt, en masse specifikationer om hvordan noget så ud i tidligere udgaver af MS Office (jeg mindes bla. at have læst om at der er temmeligt mange forskelige "borders" beskrevet). Jeg er overhovedet ikke ekspert på området, men efter min mening så er en ny dokument specification der er tænkt som basis for rigtig mange ting, ikke det rette sted at dokumentere det. Jeg vil mene at det burde blive i specifikationerne til de tidligere formater. Derefter skulle man så selvfølgeligt lave et import filter baseret på disse.

Det jeg er ude efter er at vi får valgt et godt og rigtig åbent dokumentformat (aabenstandard.dk). ODF er helt sikkert ikke perfekt, men min klare fornemmelse er at det er en bedre basis end OOXML, bla. fordi det aktivt bliver udviklet i et åbent forum.

Jesper Lund Stocholm

Jørgen,

> Det er vel næppe overraskende? Specielt ikke når
> formaterne er proprietære.

Hvad mener du?

> Jeg er overhovedet ikke ekspert på området

> men efter min mening så er en ny dokument
> specification der er tænkt som basis for rigtig
> mange ting, ikke det rette sted at dokumentere
> det. Jeg vil mene at det burde blive i
> specifikationerne til de tidligere formater.

Jeg synes, at du vender tingene lidt på hovedet. I OOXML er fx en hel del sider afsat til at specificere VML-formatet. Dette skyldes, at tidligere versioner af Office-filer indeholdt grafik i VML-form. For at sikre bagudkompatibilitet med eksisterende Office-filer er dette nu taget med i OOXML, så de kan behandles korrekt. En debattør i et af de indlæg jeg tidligere har refereret til formulerede det således [efter min hukommelse]: "Nu har vi i OSS-verdenen i årevis forsøgt at få Microsoft til at afdække deres formater, og nu da de endelig gør det, så brokker folk sig over, at 1) der er for meget af det og 2) det står det forkerte sted".

> ODF er helt sikkert ikke perfekt,

Hvorfor er det altid det eneste, man kan vriste ud af fortalerne for "ODF-alene"-beslutningen? Kan du ikke kvalificere det lidt mere og forklare, hvorfor de "ikke-perfekte" ting ikke er relevante eller vigtige nok?

> men min klare fornemmelse er at det er
> en bedre basis end OOXML, bla. fordi det aktivt
> bliver udviklet i et åbent forum.

Med andre ord så er dit bedste argument, at formatet vedligeholdes af OASIS og ikke ECMA? Er der slet ikke nogen tekniske aspekter, som du synes kunne være interessante i forbindelse med valg af format?

At formatet bliver vedligeholdt i et åbent forum er /ikke/ en garanti for kvalitet. Bla. har de formastet sig til at sende en version af ODF til godkendelse i ISO, der 1) ikke specificerer hvordan formler skal dannes og 2) tillader applikationsspecifikke udvidelser. Specielt IBM taler jo meget om "100% interoperabilitet", men alligevel har de valgt et design, der i praksis umuliggør netop dette.

Og så spørger jeg dig igen (med håb om svar): Hvorfor er disse ting ikke vigtige?

Jørgen Ramskov

>> Det er vel næppe overraskende? Specielt ikke
>> når formaterne er proprietære.
>
> Hvad mener du?

At det vel næppe er overraskende at MS er de eneste der kan levere fuld understøttelse for deres egne, proprietære formater.

=== KLIP ===
Jeg synes, at du vender tingene lidt på hovedet. I OOXML er fx en hel del sider afsat til at specificere VML-formatet. Dette skyldes, at tidligere versioner af Office-filer indeholdt grafik i VML-form. For at sikre bagudkompatibilitet med eksisterende Office-filer er dette nu taget med i OOXML, så de kan behandles korrekt.
=== KLIP ===

Jeg forstår forsat ikke hvorfor det skal være en del af specifikationen? Ja, det nye format bør supportere det meste af hvad de gamle formater kan, men jeg mener ikke den bagudkompabilitet bør være en del af specifikationen, feks er der nævnt noget der stammede tilbage fra en gammel version af Notes. Det virker på mig komplet tåbeligt at have sådan noget i et nyt, moderne dokument standard.

For mig virker det langt mere logisk at lave et import filter til at håndtere alle disse gamle bugs osv., jeg kan ikke umiddelbart finde nogen god grund til at gøre det anderledes?

=== KLIP ===
En debattør i et af de indlæg jeg tidligere har refereret til formulerede det således [efter min hukommelse]: "Nu har vi i OSS-verdenen i årevis forsøgt at få Microsoft til at afdække deres formater, og nu da de endelig gør det, så brokker folk sig over, at 1) der er for meget af det og 2) det står det forkerte sted".
=== KLIP ===

Hvis det er korrekt, så er det en god nyhed, men så vidt jeg ved så har Microsoft lavet et nyt format der er ganske åbent (OOXML), men specifikationerne til de formater som 99,9% af alle dokumenter ligger i, er så vidt jeg ved fortsat ikke tilgængelige?

=== KLIP ===
> ODF er helt sikkert ikke perfekt,

Hvorfor er det altid det eneste, man kan vriste ud af fortalerne for "ODF-alene"-beslutningen? Kan du ikke kvalificere det lidt mere og forklare, hvorfor de "ikke-perfekte" ting ikke er relevante eller vigtige nok?
=== KLIP ===

Jeg tror ikke jeg har påstået at de ikke var vigtige? Jeg har tværtimod sagt at der så vidt jeg kan se arbejdes på at tilføje disse mangler til ODF. Derudover så mener jeg ikke MS (jeg ved godt du ikke repræsenterer MS) kan klage over mangler i ODF - de har haft alle chancer for at være en del af processen med at standardisere ODF men de har selv valgt ikke at deltage. At komme bagefter og kritisere ODF (hvilket de har gjort) er hykleri efter min mening.

=== KLIP ===
Med andre ord så er dit bedste argument, at formatet vedligeholdes af OASIS og ikke ECMA? Er der slet ikke nogen tekniske aspekter, som du synes kunne være interessante i forbindelse med valg af format?
=== KLIP ===

Jeg synes du fejlfortolker mine svar. Jeg har ikke sagt at det var mit bedste argument, men jeg mener det er en væsentlig del for at kalde en standard for en åben standard at det vedligeholdes i et åbent forum hvor alle har mulighed for at deltage. Er du uenig i det?

Mht. tekniske aspekter så har jeg besvaret det allerede.

=== KLIP ===
At formatet bliver vedligeholdt i et åbent forum er /ikke/ en garanti for kvalitet. Bla. har de formastet sig til at sende en version af ODF til godkendelse i ISO, der 1) ikke specificerer hvordan formler skal dannes og 2) tillader applikationsspecifikke udvidelser. Specielt IBM taler jo meget om "100% interoperabilitet", men alligevel har de valgt et design, der i praksis umuliggør netop dette.
=== KLIP ===

Det er helt rigtigt at det ikke er en garanti for kvalitet, men det tror jeg heller ikke der er nogen der påstår?

Igen, så vil det blive ændret med version 1.3 og jeg vil da gætte på at den nuværende ODF ISO standard bliver opdateret med det.

=== KLIP ===
Og så spørger jeg dig igen (med håb om svar): Hvorfor er disse ting ikke vigtige?
=== KLIP ===

Det har jeg allerede svaret på, men jeg kan da uddybe ved at spørge om hvem der mener det ikke er vigtigt eller hvor det lige er at jeg har sagt det? Jeg synes bestemt det lyder som en vigtig del.

Jesper Lund Stocholm

> At det vel næppe er overraskende at MS er de
> eneste der kan levere fuld understøttelse for
> deres egne, proprietære formater.

Min pointe er, at det er positivt, at der nu lukkes op for formaterne - uanset om de tidligere har været lukkede eller ej.

> Jeg forstår forsat ikke hvorfor det skal være en
> del af specifikationen? Ja, det nye format bør
> supportere det meste af hvad de gamle formater
> kan, men jeg mener ikke den bagudkompabilitet
> bør være en del af specifikationen,

Hvis du tager fat i OOXML-spec og kigger i kapitel 5 (VML og DrawingML), så kan du se forklaringen. Her står der (mine ord):

"VML er det format, som tidligere versioner af Office-docs anvendte og spec for VML er taget med for at sikre fuld support for disse. Nye OOXML-dokumenter anbefales at anvende den mere moderne DrawingML-standard".

Med andre ord: Hvis du i OpenOffice.org åbner fx et Word2003-dokument med grafik i, så er grafikken gemt som VML. Fordi spec for VML er inkluderet i OOXML, så kan du "blot" putte grafikken over i dit nye OOXML-dokument og skal ikke først konvertere det til DrawingML. Jeg kan ikke se, hvorfor dette er så galt, at OOXML skal fravælges af den grund.

> så vidt jeg ved så har Microsoft lavet et nyt
> format der er ganske åbent (OOXML), men
> specifikationerne til de formater som 99,9% af
> alle dokumenter ligger i, er så vidt jeg ved
> fortsat ikke tilgængelige?

Men de bliver tilgængelige ved anvendelse af ODF? Hvis ikke, hvorfor er det så et argument /imod/ OOXML?

> de har haft alle chancer for at være en del af
> processen med at standardisere ODF men de har
> selv valgt ikke at deltage. At komme bagefter og
> kritisere ODF (hvilket de har gjort) er hykleri
> efter min mening.

Helt overordnet mener jeg ikke, at det er rimeligt at pådutte selvstændige og konkurrerende firmaer krav om at arbejde sammen. Men siden du mener, at Microsoft "burde" gøre noget, så kunne jeg jo tilsvarende sige, at IBM, Sun et al. "burde" have støttet op omkring arbejdet med den OSS ODF-converter som Microsoft financielt støtter på SourceForge. Men de har valgt at køre deres eget spor - ganske som Microsoft gjorde med OOXML - og at komme bagefter og kritisere OOXML for mangel på interoperabilitet "er hykleri efter min mening" ;o)

> Jeg synes du fejlfortolker mine svar. Jeg har
> ikke sagt at det var mit bedste argument, men
> jeg mener det er en væsentlig del for at kalde
> en standard for en åben standard at det
> vedligeholdes i et åbent forum hvor alle har
> mulighed for at deltage. Er du uenig i det?

Det er vel et nuancespørgsmål. Jeg synes at det er fint, hvis en standard vedligeholdes i et åbent forum, men en "åben standard" for mig behøver ikke at kræve det. Hvis du kigger på standarderne på standarder.oio.dk, så vil dit krav om "åbent forum hvor alle har mulighed for at deltage" effektivt spærre for anvendelse af en lang, lang række standarder. Derfor mener jeg ikke, at dit krav skal være ultimativt - og det er (jeg beklager udtrykket) uigennemtænkt at kræve det som en præmis for at godkende en standard. Vil du heller ikke have, at vi skal bruge WS*-standarderne?

http://standarder.oio.dk/Dansk/Infosider/46.html

eller hvad med krypteringsalgoritmer?

http://standarder.oio.dk/Dansk/Infosider/102.html

AES blev jo valgt på baggrund af forslag fra hele verden til krypteringsalgoritmer og blev gradvist indsnævret til 5, hvoraf Rijndael til sidst blev valgt. Selve optagelsesprocessen var offentlig men selve beslutningsprocessen var ikke. Det var altså ganske meget som beslutningsprocessen for ECMA/OOXML.

> Igen, så vil det blive ændret med version 1.3

Se, dette er faktisk et af de aspekter som vi har snakket mindst om overhovedet - men til gengæld reelt det mest spændende, nemlig: Hvad kommer politikerne til at beslutte? Der er vel ingen tvivl om, at det for OOXMLs vedkommende drejer sig om ECMA-versionen. Men hvad mon de kommer til at vælge med ODF? Bliver det v1.0, v1.1, v1.2 eller v.1.3? Når man tænker på, hvor meget "I" har råbt og skreget omkring OOXMLs manglende ISO-certificering, så hælder jeg til at tro, at de nok vælger at v1.0 skal anvendes. Jeg tror i hvert fald ikke på, at de vil vælge "ODF version .". Men det betyder så også, at det for nuværende er ligegyldigt, hvad der kommer af features i fremtidige versioner af ODF, for den offentlige forvaltning skal overholde den laveste fællesnævner, nemlig v1.0. Den er derfor tvunget til at vedligeholde systemer med understøttelse af et format, der i mine øjne ikke er produktionsmodent endnu, og /du/ risikerer at dine ODF-filer i v1.3 (fra din KOffice) ikke kan læses af din kommune.

> og jeg vil da gætte på at den nuværende ODF ISO
> standard bliver opdateret med det.

Det tror jeg også, men på et tidspunkt må politikerne jo trække en streg i sandet og vælge version - og det bliver sandsynligvis ikke v1.3 .

> Jeg synes bestemt det lyder som en vigtig del.

Men jeg forstår ikke, hvorfor du ikke synes, at de er /vigtige nok/. Du mener jo, at OOXML skal afvises bla. pga. (ret mig, hvis jeg tager fejl):

Spec indeholder bagudkompatible afsnit
Spec er ikke vedligeholdt i "et åbent forum"
Spec anvender ikke eksisterende standarder

Hvorfor mener du så ikke, at ODF skal afvises pga:

Spec er mangelfuld (ingen formelspec for regneark)
Spec modarbejder interoperabiitet (app specifikke namespaces)

?

Kritikken imod OOXML er jo, at de nævnte forhold gør implementering af standarden mere kompleks end nødvendigt er. Men de nævnte forhold for ODF er jo ganske enkelt eksempler på dårligt håndværk. Hvorfor betyder de ikke nok? Dit argument med, at "det kommer nok i version 1.3" holder ikke, for inden den er kommet fra OASIS og er blevet godkendt af ISO, så har Folketinget taget stilling til en version af ODF, der ikke har disse ting i sig.

Jørgen Ramskov

Jesper:

=== KLIP ===
Min pointe er, at det er positivt, at der nu lukkes op for formaterne - uanset om de tidligere har været lukkede eller ej.
=== KLIP ===

Det er helt sikkert positivt at vi går i retningen af mere åbne formater.

=== KLIP ===
Med andre ord: Hvis du i OpenOffice.org åbner fx et Word2003-dokument med grafik i, så er grafikken gemt som VML. Fordi spec for VML er inkluderet i OOXML, så kan du "blot" putte grafikken over i dit nye OOXML-dokument og skal ikke først konvertere det til DrawingML. Jeg kan ikke se, hvorfor dette er så galt, at OOXML skal fravælges af den grund.
=== KLIP ===

Igen uden at være ekspert, så synes jeg det lyder som en rigtig dårlig løsning. Jeg ville da helt klart foretrække at det nye format kun indeholdte "DrawingML". Jeg kan ikke se det fornuftige i at have begge dele i en standard. Medmindre du eller andre kan give mig en god grund, så mener jeg det bør ligge i et import filter (eller hvad man nu foretrækker at kalde det).

=== KLIP ===
> så vidt jeg ved så har Microsoft lavet et nyt
> format der er ganske åbent (OOXML), men
> specifikationerne til de formater som 99,9% af
> alle dokumenter ligger i, er så vidt jeg ved
> fortsat ikke tilgængelige?

Men de bliver tilgængelige ved anvendelse af ODF? Hvis ikke, hvorfor er det så et argument /imod/ OOXML?
=== KLIP ===

Jeg forstår ikke hvad du mener? 99.9% af alle dokumenter ligger i .doc og .xls formaterne - det er lukkede formater så vidt jeg ved. Det er ikke et argument imod OOXML, men at OOXML er åben gør ikke de tidligere formater åbne.

=== KLIP ===
Helt overordnet mener jeg ikke, at det er rimeligt at pådutte selvstændige og konkurrerende firmaer krav om at arbejde sammen.
=== KLIP ===

Det har jeg heller skrevet...

=== KLIP ===
Men siden du mener, at Microsoft "burde" gøre noget, så kunne jeg jo tilsvarende sige, at IBM, Sun et al. "burde" have støttet op omkring arbejdet med den OSS ODF-converter som Microsoft financielt støtter på SourceForge. Men de har valgt at køre deres eget spor - ganske som Microsoft gjorde med OOXML - og at komme bagefter og kritisere OOXML for mangel på interoperabilitet "er hykleri efter min mening" ;o)
=== KLIP ===

Nu kom ODF jo lang tid før OOXML...

=== KLIP ===
Det er vel et nuancespørgsmål. Jeg synes at det er fint, hvis en standard vedligeholdes i et åbent forum, men en "åben standard" for mig behøver ikke at kræve det. Hvis du kigger på standarderne på standarder.oio.dk, så vil dit krav om "åbent forum hvor alle har mulighed for at deltage" effektivt spærre for anvendelse af en lang, lang række standarder. Derfor mener jeg ikke, at dit krav skal være ultimativt - og det er (jeg beklager udtrykket) uigennemtænkt at kræve det som en præmis for at godkende en standard. Vil du heller ikke have, at vi skal bruge WS*-standarderne?
=== KLIP ===

Det kan du godt have ret i, det er ikke sort/hvidt. Det er ikke nødvendigvis relevant i alle tilfælde, det kommer an på hvor en given standard skal bruges, men jeg mener det er ret relevant for disse dokumentformater.

=== KLIP ===
AES blev jo valgt på baggrund af forslag fra hele verden til krypteringsalgoritmer og blev gradvist indsnævret til 5, hvoraf Rijndael til sidst blev valgt. Selve optagelsesprocessen var offentlig men selve beslutningsprocessen var ikke. Det var altså ganske meget som beslutningsprocessen for ECMA/OOXML.
=== KLIP ===

Hvis det er tilfældet, så kunne man vel sige at ODF allerede findes i ISO så udvælgelsen er foretaget og OOXML bør droppes ;)

=== KLIP ===
Det tror jeg også, men på et tidspunkt må politikerne jo trække en streg i sandet og vælge version - og det bliver sandsynligvis ikke v1.3 .
=== KLIP ===

Det har du måske ret i, men omvendt vil man, hvis det er kompetente folk der sidder og skal tage den beslutning, måske nok gå efter version 1.3.

=== KLIP ===
Men jeg forstår ikke, hvorfor du ikke synes, at de er /vigtige nok/. Du mener jo, at OOXML skal afvises bla. pga. (ret mig, hvis jeg tager fejl):

Spec indeholder bagudkompatible afsnit
Spec er ikke vedligeholdt i "et åbent forum"
Spec anvender ikke eksisterende standarder

Hvorfor mener du så ikke, at ODF skal afvises pga:

Spec er mangelfuld (ingen formelspec for regneark)
Spec modarbejder interoperabiitet (app specifikke namespaces)

?
=== KLIP ===

Nu må du altså holde op Jesper! Jeg har ikke påstået nogen af delene! Læs venligst hvad jeg skriver, ikke hvad du tror jeg mener. Det er irriterende at blive ved med at påpege det :(

Jesper Lund Stocholm

... jeg tror, at vi er nødt til at træde et skridt tilbage, nu da vi er nået 100-indlægs-mærket ... og jeg er i hvert fald nødt til at skrive nogle kortere indlæg - jeg synes i hvert fald selv, at det er ved at være svært at over skue vores samtale :o)

Men nu da jeg har reflekteret lidt over diskussionen, så tror jeg, at jeg har kan se, hvorfor vi har svært ved at overbevise hinanden om, at vi hver især har ret. Det skyldes i min optik (grimt udtryk, jge ved det godt) at vi har forskellige prioriteter. Du kigger på selve standardiseringsprocessen, arbejdsgangene i de enkelte standardiseringsorganer og dermed om i hvor vid udstrækning formaterne kan kaldes for "åbne". Sådan virker dine argumenter i hvert fald på mig :o)

Jeg er derimod mere fokuseret på teknikken. Om formatet er standardiseret i ECMA eller ISO, om ODF eller OOXML kom først eller hvem der har hvilke politiske dagsordner er for mig ikke så vigtigt. Jeg kommer til at arbejde med formaterne i praksis og derfor er deres tekniske muligheder (og mangler) mere vigtige for mig end politikken bag dem. Jeg mener nemlig, at der i det store hele politisk set ikke er forskel i hverken "ondskab" eller "godhed" for de to fløje i kampen.

Hvis jeg skal se overordnet på de to formater fra en "markup-mæssig" side, så tror jeg, at ODF bliver nemmere at arbejde med end OOXML. Det virker som om, at ODF har valgt en "XML-tilgangsvinkel", der ligger tæt op ad den måde, som vi andre bruger XML på i det daglige og i øvrigt som HTML er bygget op i dag. Derfor tror jeg, at det bliver (noget) nemmere at arbejde med ODF-xml-formatet end med OOXML-xml-formatet. Jeg vil ikke genåbne SVG/DrawingML-diksussionen igen, men jeg ser også anvendelsen af fx SVG som positiv, og jeg glæder mig til at arbejde med det.

Hvis jeg ser på de to formater fra en teknisk/funktionel vinkel og tænker på, hvilke problemer med interoperabilitet de kunne medføre i det daglige arbejde med formaterne, så vinder OOXML. Det fremstår alt i alt som et mere gennemført og færdigt format, og jeg har ikke set designmæssige "brølere" som de applikationsspecifikke udvidelser til ODF samt manglende formel-sepc. Det virker ganske enkelt som om, at Microsoft har brugt mere tid på at få OOXML til at blive et /godt/ format end IBM, Sun etc har i deres ODF-format.

Jeg ved ikke om jeg vil udråbe en personlig vinder af ODF eller OOXML, for de skiftes til at vinde på de enkelte fronter. Men jeg mener helt konkret, at det vil være en katastrofe kun at vælge ODF, da dets mangler kommer til at betyde massive udgifter i form af problemer med interoperabilitet. Da jeg ikke mener - som René og andre - at det nødvendigvis skal være et "enten-eller"-spørgsmål men mere et "både-og"-spørgsmål [0], så synes jeg, at politikerne skal have mandsmod nok til at vælge at anbefale begge formater.

... og god pinse herfra :o)

(og så endte jeg sgu alligevel med at skrive et langt indlæg)

[0] http://notes2self.net/archive/2006/09/11/OpenXML-and-ODF-2D00-it_2700_s-not-a-zero-sum-game_2E00_.aspx

Jørgen Ramskov

Jeg mener stadigt det vil være en fejl at vælge 2 formater. Det giver simpelthen ikke mening at vælge 2 - det vil give en masse dobbeltarbejde. Jeg ved ikke om der er store mangler udover de der allerede er ved at blive tilføjet i næste version? Det skal der selvfølgeligt styr på, men jeg mener det er vigtigt at vi får noget konkurrence på markedet igen og det tror jeg ikke vi får ved at vælge OOXML.

Ebbe Hansen

argumenter for at det skulle give mening at lave to forskellige xml-formater til håndtering af standard dokumenter.

jeg er ikke specielt religiøs omkring det ene eller det andet formet, men jeg fatter altså ikke at der skal være to!

På sigt kan det kun give bøvl, at der ikke findes én standard for dokumenter i det offentlige.

Måske kunne der være tekniske begrundelser for forskellene, men der er jeg nærmest kold.
Mit behov er et dokumentformat, der giver samme kvalitet uanset om det er moster Karen, der sidder på en windowsæske i Løgumkloster, direktør Svenning der sidder på en webcafe i Cairo eller told&skat på en linux-æske på Østerbro. Uden at hverken de eller jeg skal lave (tabsgivense) konverteringer.

Og hvis et åbent dokumentformat ikke er åbent nok til at alle kan benytte det uden at betale licens, så er det ikke betegnelsen åbent værdigt :-|

Jesper Lund Stocholm

> argumenter for at det skulle give mening at lave
> to forskellige xml-formater til håndtering af
> standard dokumenter.

Indgangsargumentet er jo, at de to formater ikke kan det samme og ikke har samme formål. Derfor er det ikke "to formater til det samme" men "to formater til to forskellige ting". På samme måde giver det heller ikke umiddelbart mening at have både et USB(2)-interface og et IEEE-1394 interface på samme computer. De kan begge bruges til at overføre data, men typisk vil man bruge USB(2) til én slags opgaver og IEEE-1394 til en anden slags opgaver. Derfor giver det mening med to standarder her.

> På sigt kan det kun give bøvl, at der ikke
> findes én standard for dokumenter i det
> offentlige.

Hvorfor egentlig? Det vigtige må vel være, at de forskellige programmer rundt omkring i den offentlige sektor kan læse (alle) de formater, som medarbejderne modtager.

> Måske kunne der være tekniske begrundelser for
> forskellene, men der er jeg nærmest kold.

sådan er vi jo heldigvis så forskellige :o)

> Og hvis et åbent dokumentformat ikke er åbent
> nok til at alle kan benytte det uden at betale
> licens, så er det ikke betegnelsen åbent værdigt
> :-|

Nemlig - og derfor er det også problematisk, at ODF-fortalerne omtaler ODF som åbent, når Sun ejer patenter, der dækker dele af ODF-spec.

... eller ... det var måske ikke det, som du hentydede til? ;o)

Jesper Lund Stocholm

> Hej Jesper,

Hejsa :o)

> Har du en datalogisk uddannelse?

Øehm - hvis du med "datalogisk uddannelse" mener, om jeg har en kandidatuddannelse i Datalogi, så er svaret nej.

> taler du mod bedre viden

Kan du ikke uddybe det lidt?

> eller det jeg frygter: Du er betalt troll!

Af hvem? Der må seriøst være nogle lønsedler, der er gået helt galt i posten. Men du har da fat i en god pointe. Eftersom jeg reelt i perioder er mere aktiv herinde end René, så /burde/ jeg måske stå på lønningslisten ved Microsoft ... men det gør jeg nu ikke.

:o)

michael rasmussen

"Øehm - hvis du med "datalogisk uddannelse" mener, om jeg har en kandidatuddannelse i Datalogi, så er svaret nej."

Jeg taler om datalogisk uddannelse i bred forstand. Dvs. en uddannelse på videregående niveau hvor datalogi er emnet.

"Kan du ikke uddybe det lidt?" Din glorificering af at to formaters er at foretrække frem for en. To formater er ingen tjent med, og det har altid været sådan i datalogien, at man har arbejdet hen imod at have en og kun en specifikation for at løse et specifikt problem. Hvorfor tror du, at designmønstre er opstået?

Et eksempel:
Når man implementerer en tilstandsmaskine er hovedregelen, at man til enhver tid foretrækker en deterministisk frem for en non-deterministisk. Overført til et pratisk eksempel. Forestil dig en nødprocedure der skal implementeres efter en non-deterministisk tilstandsmaskine. Hvordan vil aktions-/tilstandsdiagrammet se ud for en sådan?

Jesper Lund Stocholm

> Jeg taler om datalogisk uddannelse i bred
> forstand. Dvs. en uddannelse på videregående
> niveau hvor datalogi er emnet.

Ok - så er svaret vel en slags 'ja'.

> Din glorificering af at to formaters er at
> foretrække frem for en.

Jeg er ked af, hvis det fremgår således af mine indlæg. Jeg mener bestemt ikke, at to standarder altid er bedre end én, men i tilfældet ODF/OOXML er mine argumenter, at

1) Der er vigtige ting i OOXML, som ODF ikke kan
2) ODF er en mangelfuld standard

Derfor argumenterer jeg for, at begge formater tillades i den offentlige sektor i Danmark.

Jørgen Ramskov

Jesper: Hvilke væsentlige mangler er er i ODF?
(Udover formler som kommer i næste version)

Man kunne også lave det tankeeksperiment at hvis MS nu havde hjulpet til med standardiseringen af ODF så havde formatet måske haft formler med i version 1.0. Personligt mener jeg det er ret ærgeligt at MS ikke har deltaget i arbejdet for de må have nogle folk med meget om emnet.

Hvad mener du med at de ikke er lavet til samme formål?

Jesper Lund Stocholm

> Jesper: Hvilke væsentlige mangler er er i ODF?
> (Udover formler som kommer i næste version)

Helt konkret mangler jeg formelspecifikation. At man kan lave et format til regneark men ikke specificere hvordan formler skal angives er for mig helt uforståeligt. Det er muligt at det virker som en lille ting, men jeg forudser ganske betragtelige problemer med at parse ODF-regneark, der er lavet i en bred vifte af implementeringer ... for hvilket format har hvilken implementering valgt?

Der er flere andre ting, som jeg synes er uheldige - men kig selv på listen på fx http://en.wikipedia.org/wiki/OpenDocument#Criticism . Jeg har tidligere refereret til OASIS-maillistens korrespondance om netop disse ting, og den taler mere eller mindre for sig selv.

Det giver ikke mening i min verden at tale om hvad "der kommer i næste version" - hverken for ODF eller OOXML. For det drejer sig ikke om, at du og jeg jo bare kan opgradere vores OpenOffice.org-programmer til seneste version for at kunne drage nytte af de nye ting i fx ODF v1.2. Indenfor ganske kort tid skal politikerne jo tage stilling, og de to versioner der ligger på bordet er i mine øjne "OOXML/ECMA 376" samt "ODF v.1.0 ISO". Jeg kan ikke i min vildeste fantasi forestille mig, at de vil sige "brug ODF version ." ... specielt ikke når man tænker på, hvor meget folk "herinde" har råbt og skreget over, at OOXML ikke er ISO-certificeret. Du har tidligere skrevet, at kompetente folk vil vælge v1.3 (eller 1.2), men jeg kan ikke se, at det er realistisk at de vælger en version, der slet ikke er færdig endnu. Derfor tror jeg - med min mest positive kasket - at de vil vælge ODF v1.0 eller i aller heldigste fald ODF v1.1. Det problem det giver mig som udvikler er dermed, at min offentlige kunde sikkert så vil komme og bede mig om at implementere et eller andet lækkert fra ODF v1.3 han har læst om i Computerworld. Men jeg er nødt til at sige nej til ham, da en implementering af et eller andet udenfor den valgte standard med sikkerhed vil give problemer i det øjeblik han sender et dokument til nabokommunen, der har holdt sig til den vedtagne v1.0.

Derfor er det et helt konkret problem for OASIS (og dermed ODF), at de har skyndt sig så meget med at blive ISO-certificerede - i stedet for at gøre formatet færdigt.

Mht Microsoft-hjælp til ODF-samarbejdet, så kan det være interessant at se på tidslinien for udviklingen af ODF og OOXML. Se evt på http://blogs.msdn.com/brian_jones/archive/2007/01/25/office-xml-formats-...

Med Brian Jones' ord:

"In addition to that, ODF and OpenXML were both designed over the same period of time so it wasn't like ODF was already widely in use before we started to work on OpenXML"

> Hvad mener du med at de ikke er lavet til samme formål?

I det oprindelige oplæg til ODF-samarbejdet blev der trukket en linie i sandet og man ønskede at lave et åbent dokumentformat med fremadrettet perspektiv. Man fravalgte helt konkret at kigge tilbage og lave formatet bagudkompatibelt. Men bagudkompabilitet var netop et kardinalpunkt for Microsoft, så det alene var grund "nok" til ikke at indtræde i ODF-arbejdet.

Jeg faldt for et par dage siden over det oprindelige "ODF-charter", der kridtede banen op for det fremtidige samarbejde om formatet. Hvis det har interesse, så kan jeg prøve at finde det igen.

:o)

PS: Brian Jones blog er altså ret interessant også i "vores" diskussion i Danmark. Det er ikke så meget hans egne artikler, der er så interessante for os, men derimod de tråde, der diskuteres i forbindelse med artiklerne. De er klart et kig værd.

Ebbe Hansen

Hej Jesper Lund Stocholm
Jeg fatter stadigvæk ikke hvorfor det skulle være nødvendigt - endsige gavnligt - med to forskellige formater.

For den almindelige bruger (og målet er vel primært deres arbejdsrutiner) kan der ingen specifikke fordele være i at gemme i det ene format frem for det andet. Ellers er der et format der ikke er egnet til dokumentlagring.

For mig giver det en lang række praktiske problemer at vælge at køre med to ikke helt kompatible formater. Primært ved informationsudveksling. Der vil givet både falde broer og dø mennesker fordi modtager ikke ser helt det samme som afsender. Men måske skal enhver dokumentudveksling ledsages af et pdf for verifikationens skyld.

Med hensyn til sammenligningen mellem IEEE1394 og usb(2), så er det i mine øjne at misforstå åben standard dokumentformats rolle (med vilje?)

Skal man bringe åben standard ind i den sammenhæng, så må sammenligningen være at det er det interface, der gør at brugeren kan tale med både usb og firewire.

Jesper Lund Stocholm

> Jeg fatter stadigvæk ikke hvorfor det skulle være
> nødvendigt - endsige gavnligt - med to forskellige
> formater.

Jeg er ikke sikker på, at det som udgangspunkt er gavnligt og jeg er heller ikke sikker på, at det som udgangspunkt er nødvendigt - hvis man ikke kigger på disskussionen i den danske kontekst.

Når jeg argumenterer for valg af to formater, så er det ikke fordi jeg glæder mig til at kunne sende både ODF-dokumenter og OOXML-dokumenter til min kommune eller fordi jeg glæder mig til at skulle implementere understøttelse for begge formater for mine offentlige kunder. Mine argumenter skyldes derimod:

  1. ODF kan ikke stå alene, da det slet ikke er modent nok til at kunne stå for dokumentudveksling i den offentlige sektor

  2. OOXML har nogle features, som jeg mener kan give ganske stor værdi i den offentlige sektor og dermed for mine kunder [*].

  3. Jeg synes det er fint med konkurrence imellem formater og deres muligheder. Dermed holdes både OASIS og ECMA til ilden.

Mht om dokumenter vises ens på alle platforme, så kan man jo aldrig garantere dette - hverken med OOXML eller ODF.

... og mht analogier, så er det min faste overbevisning, at man skal afholde sig fra dem, da de 1) altid kan pilles fra hinanden og 2) ofte misforståes. Når jeg alligevel tog det med, så var det for at banke en pæl igennem argumentet med, at det som udgangspunkt aldrig er en god idé med to standarder på samme arbejdsområde.

:o)

og ... og dette er bestemt ikke flame-bait, men dog lidt OT ... jeg må indrømme, at jo mere jeg læser om ODF jo mere skeptisk bliver jeg over formatet og dets modenhed. Man kan kritisere OOXML for mange ting herunder standardiseringsorgan, omfang, manglende anvendelse af eksisterende standarder, mystisk XML-markup m.fl. Men man kan ikke - hvis du spørger mig - kritisere OOXML for at være et fattigt og skrabet format. Det virker som om, at Microsoft har gjort sig umage med netop at gøre hvad de sagde: lavet et dokumentformat, der er bagudkompatibelt med eksisterende Office-dokumenter og som kan repræsentere det samlede indhold af et givet MS-Office dokument. Dette format har de så offentliggjort. Man kan slet ikke sige det samme om OASIS. De har skyndt sig alt for meget med at blive færdige med ODF - sikkert for at blive "første ISO-standard". Men konsekvensen er blevet et format, der er direkte mangelfuldt specificeret og hvor de har taget nogle design-valg, der for mig er helt hul i hovedet (app-specifikke udvidelser). Derudover har OASIS og andre ODF-støtter malet sig op i et "ISO-only"-hjørne ved hele tiden at afvise OOXML med argumenter om, at det ikke er en ISO-standard. Men netop ISO-versionen af ODF er så tynd at det vil være en katastrofe at vælge den alene. Dermed tvinger de reelt os andre til at argumentere for to standarder og politikerne til at vælge mere end blot ODF.

[*] Med "mine kunder" mener jeg naturligvis de kunder vi har i det firma jeg arbejder i

René Løhde

Hej Jesper,

Angående din sidste kommentar om ODF i relation til ISO vil jeg spørge om du på noget tidspunkt i din research (!) er stødt på hvordan jeg kan kende forskel på OASIS ODF version og ISO ODF versionen?

(- og, ja, jeg kunne jo bare købe spec'en fra ISO's side, men det er uden for scope for mig pt)

Jeg har prøvet at åbne flere dokumenter fra flere ODF implmenteringer og kigge namespaces igennem idet jeg vil forvente at der kunne være et namespace, som var tilknyttet ISO - no luck indtil videre har jeg ikke kunnet finde noget ISO "touch".

Har andre samme erfaring?

-René

Jesper Lund Stocholm

Hvis jeg forstår dig rigtigt, så spørger du, hvordan du kan kende de forskellige ODF-versioner fra hinanden?

Jeg ved det faktisk ikke. Hvis jeg åbner content.xml-filen i et Calc-ODF-dokument lavet i OpenOffice.org (dansk version) v. 2.2, så står der i namespace-erklæringerne:

xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" xmlns:style="urn:oasis:names:tc:opendocument:xmlns:style:1.0" xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0" xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" xmlns:draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" xmlns:fo="urn:oasis:names:tc:opendocument:xmlns:xsl-fo-compatible:1.0" xmlns:xlink="http://www.w3.org/1999/xlink&quot; xmlns:dc="http://purl.org/dc/elements/1.1/&quot; xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0" xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0" xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0" xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0" xmlns:math="http://www.w3.org/1998/Math/MathML&quot; xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0" xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0" xmlns:ooo="http://openoffice.org/2004/office&quot; xmlns:ooow="http://openoffice.org/2004/writer&quot; xmlns:oooc="http://openoffice.org/2004/calc&quot; xmlns:dom="http://www.w3.org/2001/xml-events&quot; xmlns:xforms="http://www.w3.org/2002/xforms&quot; xmlns:xsd="http://www.w3.org/2001/XMLSchema&quot; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot; office:version="1.0"

Jeg ville egentlig have forestillet mig, at der havde stået "1.1" nogle flere steder, da jeg troede, at OpenOffice.org 2.2 havde implementeret v1.1 af ODF.

Leif, kan du måske hjælpe her?

:o)

PS: I betragtning af, at ISO jo blot godkender en standard, så ville jeg slet ikke forvente, at "ISO" skulle fremgå af namespaces i formatet. Til gengæld ville jeg nok have forventet, at der ville stå noget i retning af

urn:oasis:names:tc:opendocument:xmlns:office:1.1
urn:oasis:names:tc:opendocument:xmlns:office:1.2
urn:oasis:names:tc:opendocument:xmlns:office:1.3

... eller lignende.

Jesper Lund Stocholm

ISO-standarden for ODF hedder: ISO/IEC 26300:2006
[0]

Den stammer oprindeligt fra OASIS OpenDocument v1.0 Specification [1]. Teksten fra OASIS-sitet er:

"OpenDocument v1.0 has been approved as the ISO and IEC International Standard ISO/IEC 26300:2006."

... så svaret på dit spørgsmål må vel være 'ja' :o)

Er der ikke nogle af jer, der har snakket så meget om ISO/non-ISO, der kan hjælpe med inf. her?

[0] http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=4...

[1] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office#odf10

Leif Lodahl

Specifikationerne findes her:
http://www.oasis-open.org/specs/index.php#opendocumentv1.1

OpenOffice.org 2.2 har implementeret version 1.0.
Jeg er ikke 100% sikker, men jeg tror ikke at 1.1 bliver implementeret i OpenOffice.org 2.3. Jeg undersøger det i den kommende uge.

Under alle omstændigheder vil der være kompatibilitet, både fremad og bagud.

Der er ingen indholdsmæssig forskel på OASIS og ISO udgaverne. OASIS udvikler og ISO godkender formatet.

Med venlig hilsen
Leif Lodahl

Jørgen Ramskov

Wikipedia artikel om OpenFormula, dvs. formular support til ODF: http://en.wikipedia.org/wiki/OpenFormula

I den finder man bla. dette:
"In 2005, Microsoft's Brian Jones noted that OpenDocument did not define spreadsheet formulas in detail (Jones, 2005). However, at the time Microsoft's competing proprietary XML format also did not include this kind of detailed specification for formulas (Wheeler, November 7, 2005).

Microsoft continued to protest that OpenDocument could not be used because it did not define a format for spreadsheet formulas, yet its own specification continued to omit any specification about formulas through April 2006. Finally, in May 2006, Microsoft also began defining formulas in its XML format, 15 months after the first version of OpenFormula and 3 months after OASIS posted its first official draft of its specification."

Det ændrer selvfølgeligt ikke ved at ODF 1.0 ikke indeholder det.

Log ind eller opret en konto for at skrive kommentarer