Microsoft: Open source-leverandører vildleder igen om OOXML

Teknologidirektør i Microsoft Danmark, Jasper Boisen slår nu fast: Microsoft vil implementere ISO-standarden IS 29500 af OOXML i første halvår af 2010. Al snak om andre versioner er techno-babble, siger han.

»Det er en and ? igen.«

Microsofts danske teknologidirektør, Jasper Bojsen, har kun hovedrysten til overs for formiddagens udmelding fra foreningen af open source-leverandører (OSL) om, at Microsofts bud på en offentlig dokumentformatstandard, OOXML, først er klar i en ægte åben udgave i 2015.

»Ligesom sidste gang, hvor OSL sammenlignede OpenOffice med sig selv, er OSL her blot ude i et desperat forsøg på at vildlede og afspore,« siger Jasper Bojsen til Version2.

»Microsoft vil implementere ISO-standarden IS 29500 af OOXML i første halvår af 2010. Al snak om 'strict'-versioner er ikke andet end techno-babble og en misfortolkning af, hvordan virkeligheden ser ud,« siger teknologidirektøren videre.

Han mener, at OSL har taget udsagnet om den lange tidshorisont for 'strict'versionen ? der skulle være kommet fra en højtplaceret Microsoft-ansat et ISO-arbejdsgruppemøde for et par uger siden ? helt ud af en kontekst for at skabe en illusion, der ikke stemmer overens med virkeligheden.

»Lige meget hvor meget OSL gerne vil vildlede, så findes der altså kun én version af ISO OOXML. Hvis OSL ikke mener, at ECMA OOXML eller alle dele af ISO-OOXML kvit og frit kan implementeres af alle, så må de jo fremlægge dokumentationen for deres påstand. Den har jeg og andre nu efterspurgt i snart tre år, dog uden at få noget meningsfuldt svar med nogen som helt form for teknisk merit« siger Jasper Bojsen.

»Essensen er: Der findes én og kun én ISO-standard. Det sætter jeg min lid til, at ekspertudvalget også er i stand til at gennemskue ? de var jo fornuftige nok, sidste gang, de var på banen,« lyder håbet fra Jasper Bojsen.

Eksperudvalget, Jasper Bojsen hentyder til, er det udvalg, der er nedsat til at hjælpe folketingspolitikerne med at træffe beslutningen om ODF eller OOXML. Udvalget består af professor dr. jur. Mads Bryde Andersen fra Københavns Universitet (formand), Jørgen Kristensen, formand for Foreningen af Kommunale It-chefer samt Kim Normann Andersen og Mogens Kühn Pedersen, begge CBS-professorer. Endelig er lektor Jens Hørlück fra Århus Universitet også med i udvalget.

Ifølge Version2's oplysninger skal ekspertudvalget i mødes med Folketingets it-ordførere i allernærmeste fremtid.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (55)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Søren Olesen

Fremragende artikel!

Det er en solid og kritisk analyse af debatten om åbne standarter. Den tager stilling til, hvem der har, hvilke interesser i debatten, og forholder deres udsagn i forholdet til interesser.

Derudover bliver sagen analyseret fra flere sider. Det er således ikke blot en ensidig videreformidling af den ene side i debattens synspunkter, men en balanceret fremstilling af både OSL's og MS's synspunkter.

  • 0
  • 0
Jakob Damkjær

Samt det man siger med det man ikke siger.

Men at man kan gøre noget er ikke det samme som det faktisk er værd at gøre det. Jeg kan sikkert bygge en rumraket af tændstikker hvis jeg lige opfandt en transmogriferingsmaskine der kunne omarrangere elementarpartiklerne frit.

Men en specifikation på 10k plus sider er det det lidt ligegyldigt at man kan "implementere" iso ooxml for det er ikke det dokument format som man skal læse for det eneste ooxml format der findes i virkeligheden er ecma ooxml.

Så indtil der er et applikation der kan læse og skrive iso standarten så er alt andet dampvaresnak og med ms historie med vaporvare så er man lidt for blåøjet hvis lægger nogle planer ud fra ms dampvarer.

Når de har leveret produktet og det rent faktisk kan bekræftes at iso ooxml er fuldt understøttet (og til den uheldige der får det job vil jeg sige god arbejdslyst og vi ses om 3 år) så kan man vende tilbage til denne diskussion.

Uheldigvis for os alle så er det ms strategi for jo længere de kan holde os i monopolistik afhængighed af office og tilhørende produkter i forskellige segmenter så ændre ingenting sig... og bizness as usual er ms mål.

Make a change say no to overprised software with vendor lockin as a feature.

Go weekend
/Jakob

  • 0
  • 0
Henrik Jensen

Men en specifikation på 10k plus sider er det det lidt ligegyldigt at man kan "implementere" iso ooxml for det er ikke det dokument format som man skal læse for det eneste ooxml format der findes i virkeligheden er ecma ooxml.

Men så kan man jo tage og implementere ECMA-376 1st edition og det er der jo også en del kontorpakker der er i gang med.

Der er også mange der er i gang med at implementere ODF 1.1/1.2 selvom de ikke er en ISO standard.

Uheldigvis for os alle så er det ms strategi for jo længere de kan holde os i monopolistik afhængighed af office og tilhørende produkter i forskellige segmenter så ændre ingenting sig... og bizness as usual er ms mål.

Men hvad er det der låser os til Microsoft Office?

  • 0
  • 0
Jan Keller Catalan

Derudover bliver sagen analyseret fra flere sider. Det er således ikke blot en ensidig videreformidling af den ene side i debattens synspunkter, men en balanceret fremstilling af både OSL's og MS's synspunkter.

Selvom det kunne være blevet samlet i én artikel, kan du finde den anden sides argumenter her:
http://www.version2.dk/artikel/12343-microsoft-ooxml-kommer-tidligst-i-2015

  • 0
  • 0
Henrik Jensen

Man kunne jo også nøjes med implemeterre docx format eller ECMA eller OOXML... eller... 30k + det løse

ARE YOU KIDDING????

Påstår du at f.eks. IBM ikke magter denne opgave at det er for stor en mundfuld for dem?

Tror du at at implementering af OOXML er en større kodeopgave med flere kodelinjer end f.eks. IBM DB2, IBM WebSphere Produkt X,Y,Z, IBM Lotus Produkt X,Y,Z osv?

Og hvordan kan du udlede hvor meget større opgaven er bare på antal sider?

Lad os nu tage specifikationerne for de gamle binære MS Office formater, .doc/.xls/.ppt de fylder sammenlagt ca. 850 sider

ECMA-376 1st. ed (den som benyttes i MS Office 2007 i dag) fylder ca. 6000-7000 sider. Den bør vel så tage ca. 7-8 gange så lang tid at implementere som MS Office binære formater ud fra din formel?

Men hvad er den funktionelle forskel på de to formater? Mit gæt vil være at funktionelt der er ECMA-376 1st. ed maksimum 10% større end de binære MS Office formater. Hvordan kan de ekstra 10% betyde at det tager 7-8 gange så lang tid at udvikle?

Og hvis vi tager ODF 1.2 som p.t. fylder ca. 1260 sider er det så korrekt at den tager ca. ½ gang længere tid at implementere end MS Office binære formater?

  • 0
  • 0
Martin Kofoed

Påstår du at f.eks. IBM ikke magter denne opgave at det er for stor en mundfuld for dem?

JEG vil i hvert fald påstå, at hvis motivet med OOXML har været at sætte en masse dygtige udviklere skakmat i meget lang tid, så ser det da ud til, at missionen vil lykkes. Disse udviklere kan ikke på samme tid udvikle lækre nye features, og samtidig er det ikke ligefremt NEMT at skaffe udviklere, som brænder for kontorapplikationer ...

To standarder til samme opgave er og bliver noget skidt. Forestil dig HTML og den fiktive "MSOML" til løsning af samme opgave. Hvor langt bagefter ville vi anslået være i dag i dén situation, givet at spec'en til "MSOML" fyldte bare halvdelen af OOXML-spec'en, og at WebKit, Gecko og Chrome skulle understøtte begge? Og hvordan ville din webside mon se ud?

OOXML var faktisk et ret klogt træk af et MS på hælene i sagen om åbne standarder. Nu har de købt nogle år mere med Office som cash cow, og stukket en kæp i hjulet på de irriterende forfølgere. Det virkede, okay, nogle få nævenyttige lande hoppede ikke på den, men i det store og hele var det da smart!

  • 0
  • 0
Henrik Jensen

To standarder til samme opgave er og bliver noget skidt

Enig, men du kommer altså bare ikke fra flere forskellige standarder og ned til en enkelt standard over en enkelt nat, med mindre du i den grad lader dine brugere i stikken.

Hvis der ikke fandtes nogle eksisterende dokumenter i verden, jamen så kunne vi starte helt på en frisk, men det er jo ikke tilfældet.

OOXML var faktisk et ret klogt træk af et MS på hælene i sagen om åbne standarder.

Hvad mener du med det?

Prøv engang at opridse historien for OOXML og ODF som du mener den er foregået fra år 2000 og frem til i dag.

og stukket en kæp i hjulet på de irriterende forfølgere

Forfølgerne ved udemærket godt at de er nødt til at kunne præstere en høj interoperabilitet med MS Office hvis de gerne vil vinde markedsandele, så intet har ændret sig for dem vil jeg mene.

Stort set samtlige af dem har jo også implementeret en god portion support for de binære MS Office formater af egen fri vilje, på trods af at de jo på ingen måde er en åben standard.

  • 0
  • 0
Henrik Jensen

Har du nogensinde brugt Lotus Notes?

Ja det har jeg. Det ligger dog efterhånden 6-7 år tilbage hvis ikke længere.

Kan dog ikke helt gennemskue om du mener at Lotus Notes er bevis for at det ville være en for stor opgave for IBM at implementere OOXML eller om du mener at det ville de sagtens kunne gøre hvis de satte sig for det.

Jeg mener jo bestemt det sidste.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Jarle,

heh :O) Jeg er sikker at du har de konkrete tal, så du er mere end velkommen at korrigere.

Et tal, der i hvert fald er noget tættere på virkeligheden er nok 6000.

Ikke mindre, hvis Microsofts hensigt var at skabe forvirring så er de klaret det. Hvorfor ellers skulle de står med hele 3 lignende formater på flere tusind side hver?

Faktisk er jeg helt sikker på, at Microsoft ville have foretrukket kun én version - den i ECMA. I forbindelse med den anden udgave (IS29500) er det langt hen ad vejen de nationale standardiseringsorganisationer og udpegede eksperter (og heriblandt jo CIBER og jeg og fx IBM), der har tvunget armen om på ryggen af Microsoft i forbindelse med de mere komplekse ændringer.

Så med Søren Gades ord, så skal skytset nok ikke så meget rettes imod Microsoft som imod sådan nogle som mig.

"The buck stops here" ...

:o)

  • 0
  • 0
Jakob Damkjær

sadly the buck does not stop there,

part of the "buck" drops in you hand (I would guess about 30 silver coins... but thats a lose estimate) but the majority of the "buck" goes straight to the untaxed and gargantuan vallet of microsoft.

To to counter one meaningless statement with one that actually makes sense,

FOLLOW THE MONEY !

PS! for the obtuse in the crowd "the buck stops here" is meaningless as very few people who have ever said those words have ever accepted responsibility for their actions and or words. If the buck (in the sense of the word meaning both money and responsibility) stopped at JLS he would quit his job and or his position as expert for ISO.

Neither will ever happen so the buck does not stop here there there or anywhere else besides when it gets to redmond and then it disappears.

/J

PS! men man kan være imponeret over at JLS har formået at mishandle meningen hos Søren Gades ord i en grad der er en minister værdig.

SG acceptere ansvaret i så høj grad at han fyre en der ikke er ham selv.
--------golfklap... x2

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Jacob,

part of the "buck" drops in you hand (I would guess about 30 silver coins...

Så du placerer mig sådan lidt imellem en Jesus-forrædder og en korrupt tosse.

Det er sgu da en meget god måde at starte ugen af på.

:o)

Jeg tager i øvrigt fuld ansvar for de beslutninger jeg har været med til at træffe - samt de ændringer, der er sket i OOXML. At [i]du[/i] mener disse beslutninger burde betyde min "afgang" er nok noget, som du må klare imellem dig og dit Id.

  • 0
  • 0
Jarle Knudsen

Et tal, der i hvert fald er noget tættere på virkeligheden er nok 6000.

docx - 6000
ECMA-OOXML - 6000
ISO-OOXML - 6000

div. rettelser og det løse 7-8000

i alt - ca. 25.000

Ikke langt væk fra 30k

Du er stadig velkommen med de korrekte tal, men jeg tvivler på at resultatet bliver væsentlig anderledes.

Hoved pointen er at der er meget meget nemmere at forholde sig (og implementere) til et dokumentformat på 600 sider end til tre der i alt destår af 25-30k sider. For IBM eller andre tunge drenge er det måske ikke problem at hyre flere udviklere, men der kan være et kæmpe problem for de små og mellemstore virksomheder.

Kompleksiteten vokser eksponentiel med antal linje eller noget i den stil jeg husker fra studier.

  • 0
  • 0
Henrik Jensen

docx - 6000
ECMA-OOXML - 6000
ISO-OOXML - 6000

div. rettelser og det løse 7-8000

i alt - ca. 25.000

Ikke langt væk fra 30k

Du er stadig velkommen med de korrekte tal, men jeg tvivler på at resultatet bliver væsentlig anderledes.

docx og ECMA-376 1st edition er ét og samme format.

For det andet tror du så ikke der er et vist overlap mellem ECMA-376 1st. edition og 2. Edition/ IS29500?

Hoved pointen er at der er meget meget nemmere at forholde sig (og implementere) til et dokumentformat på 600 sider

Men igen jeg mener ikke at antal sider siger alt.

Er Microsoft Office Binære formater ½ gang hurtigere at implementere end ODF? Specifikation af MS Office binære formater fylder jo ca. 850 sider og ODF 1.2 ca. 1260 sider, så det må den vel være ud fra din formel?

Og hvorfor skulle implementering af ECMA-376 1st. edition tage 7-8 gange så lang tid som Micorsoft Office Binære formater blot fordi at specifikationen indeholder 7-8 gange flere sider? Hvor ser du at den store funktionelle forskel mellem MS Office binære formater og ECMA-376 1st. edition ligger, der berettiger denne meget store forskel i implementeringstid?

Hvis nu man i forbindelse med godkendelsen af ODF 1.2 finder ud af at der er nogle elementer der ikke er beskrevet grundigt nok og man så tilføjer sammenlagt ekstra 40 sider med yderligere præcisering mv. og derved lander omkring de 1300 sider, vil du så påstå at ODF 1.2 i den godkendte udgave er blevet dårligere og tager længere tid at implementere end de ca. 1260 sider der ligger i kladde p.t.?

  • 0
  • 0
Henrik Jensen

nemmere at forholde sig (og implementere) til et dokumentformat

Men brugerne har ikke kun ét dokumentformat og det så uanset om samtlige myndigheder i verden i morgen bestemte sig for at de kun ville benytte ODF.

Prøv engang at se på de eneste brugerundersøgelser der er foretaget for OpenOffice.org. Næsten 50% ud af de små 129.000 besvarelser nævner import af word dokumenter som en af de funktioner de vil benytte og 43%+ nævner eksport til word dokumenter.

I 2008 undersøgelsen spurgte man blandt andet om hvilke områder brugerne helst så der blev forbedret i OpenOffice.org. Topscoreren var MS Office 2007 kompatibilitet efterfulgt af PDF import/eksport og herefter MS Office 2003 kompatibilitet.

og det har Microsoft jo også måttet sande. Deres umådelige ressourcer til trods, er det jo ikke lykkedes dem at lave en implementering af ODF, der når de andre til sokkeholderne.

Hvem andre tænker du på udover Sun?

Men der er da helt sikkert plads til forbedring med Microsofts implementering men det tror jeg nu nok også skal komme. Om ikke andet så når ODF 1.2 begynder at blive standard i kontorpakkerne.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Peter,

Vi sender lige en stille tak til JLS...

Jeg var ellers på vej i seng, men jeg er glad for, at jeg lige nåede at få din besked med.

:o)

Der er adskillige andre, som er nævnt i indtil flere diskussionstråde som du før har deltaget i.

Som ikke er baserede på OOo kodebase? Udviklingen på ODF-fronten går saftsusemig hurtigt, for det vidste jeg ikke var tilfældet.

  • 0
  • 0
Henrik Jensen

Vi sender lige en stille tak til JLS...

Jesper har da så vidt jeg ved hverken været med til at udvikle de binære MS Office formater eller ECMA-376 1st. edition.

Der er adskillige andre, som er nævnt i indtil flere diskussionstråde som du før har deltaget i. Jeg gider ikke at remse dem op en gang til.

Dem der jo oftest bliver nævnt det er jo sådan noget som OpenOffice.org, Novell Edition, IBM Lotus Symphony, NeoOffice m.v. De har jo alle bare kopieret den implementering som OpenOffice.org (Sun) har lavet af ODF.

Når vi snakker kontorpakker der har deres egen implementering af ODF så tror jeg faktisk at MS Office hører med blandt de allerbedste hvis det ikke er den bedste implementering.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Peter,

Den manglende relevans af dette er også blevet påpeget indtil flere gange. Det er jo lige præcis fordelen ved Open Source.

Sov godt.

Jowjow, men det siger jo kun en masse om Open Source og ikke en rygende fis om ODF. Hvis du vil bruge "antal implementeringer" til at konkludere noget om noget som helst, så er du nødt til at finde nogle implementeringer, hvor der er større forskel end en genkompilering med ændret tekst i splash-screen.

Efter "antal implementeringer"-tankegangen ville DOC-filer jo i øvrigt være "baserede på det bedste format i verden". Der er INTET dokumentformat, der er bredere understøttet i kontorpakker på tværs af platforme end de binære dokumentformater fra Microsoft, men for alle os, der har læst i specifikationerne for de binære formater, vil argumenter som "DOC er implementeret i alle mulige kontorpakker og derfor bedst" mest af alt lyde som ... øh ... "uigennemtænkt", for det er kropumuligt at finde hoved og hale i specifikationerne for formatet.

(med mindre man altså taler binært)

  • 0
  • 0
Henrik Jensen

Den manglende relevans af dette er også blevet påpeget indtil flere gange. Det er jo lige præcis fordelen ved Open Source.

Hvis samtlige kontorpakker i verden de skal laves ved at kopiere OpenOffice.org kildekoden for at opnå interoperabilitet så opnår vi følgende

1) ODF standarden bliver reelt overflødig da Sun (Oracle) til en hver tid bare kan afvige fra standarden hvis de har lyst og ingen vil bemærke det. Bortset fra at andre kan kopiere koden så er vi altså ikke nået spor længere end vi var med MS Office binære formater og Microsofts fulde kontrol at dette format.

2) Sun (Oracle) får ekstemt meget magt da de er de eneste i verden som har en copyright på den eneste ODF implementering, OpenOffice.org og kan derfor bestemme hvordan de vil licensere OpenOffice.org til forskellige organisationer m.v.

Hvis ovenstående er tilstrækkelig åbenhed så kunne vi jo også bare have forsat med StarOffice 5.2 binære formater. Dem er der jo også fin support for hvis man blot kopierer OpenOffice.org kildekoden.

  • 0
  • 0
Jakob Damkjær

>>>Så du placerer mig sådan lidt imellem en Jesus-forrædder og en korrupt tosse.

Let overfortolkning kan lede mange interessante steder hen.
Men hvis du nu er af den mening at SG er en tosse så kan jeg
se hvor du kommer fra. Men jeg forstår så ikke at du citere ham
hvis det er din holdning ??

>>Det er sgu da en meget god måde at starte ugen af på.

>>Jeg tager i øvrigt fuld ansvar for de beslutninger jeg har været med til at træffe - samt de ændringer, der er sket i OOXML. At du mener disse beslutninger burde betyde min "afgang" er nok noget, som du må klare imellem dig og dit Id.

At drømme om en bedre fremtid hvor den sygdom microsoft er noget man ser tilbage på som en rigtig dårlig ide, vi tog ud bag skuret og efterlod der, er en tanke der bringer megen trøst i den jammerdal windows er.

Ja, jeg indrømmer det blankt, jeg lod mig overtale til endnu engang at gå med til at bruge en windows maskine og endnu engang er jeg blevet overbevist om at det er noget ubrugeligt skrammel. Denne gang var det et peltierkølet kamera til 400.000 Kr, som windows tabte USB forbindelsen til når windows gik i sleepmode. Damn det er flot klaret at man ikke kan opretholde et USB enheds tabel gennem sleepmode. FAIL. Problemet løst vi slår sleepmode fra, men ak for windows slog den til igen... for det er svært at huske indstillinger i mere end 3 måneder, dobbelt FAIL.

Hvordan det eller noget andet kan relatere til mit id har jeg, undskyld min tone, relativt svært ved at se på hvilken planet de to kan kobles sammen.

Det har i allerhøjeste grad noget at gøre med mit overjeg og ego, helt specifikt min retfærdighedssans og den vedvarende overskridelse af moralske, etiske og lovmæssige rettesnore jeg har været vidne til microsoft og de tilknyttede virksomheder har overtrådt gennem tiderne. Se der er en klar sammenhæng.

Hurtig ordbog:

Id'et (Det'et) er menneskets primitive urinstinkt, som styres af lystprincippet.

Det lystdrevne menneske vil ofte blive beskrevet, ifølge en religiøs dogmatisk moral, som skyldig i dødsynden Avaritia bedre kendt som griskhed.

Griskhed eller grådighed er den last, man lider af, når man er grådig.
Det vil sige, når man er grisk, har man et stort ønske om at få meget af noget, det kan f.eks. være mad, penge eller magt. Griskhed ses ofte som noget negativt af samfundet. Griskhed hører med til de syv, utilgivelige dødssynder.

Se nu kan man læse det man vil ud fra denne tekst, men teksten læses af læseren, men man kan så læse læseren fra hvad han eller hun læser det er da næsten magisk.

Men for at opsumere det jeg mener, så mener jeg at der er stærk empiri for at microsoft og alle de virksomheder der faciliterer dem er nogle grådige lovbrydere, der burde straffes for deres forbrydelser mod den danske stat og folk.

Ikke mere ikke mindre, det er mit skålpund kød.

/J

PS! min tidligere reference til Judas overfortolkede du en smule. Der var og er mange der tog sine 30 sølvmønter, men det var faktisk kun Judas der forrådte Jesus.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Jakob,

Hurtig ordbog:

Id'et (Det'et) er menneskets primitive urinstinkt, som styres af lystprincippet.

Det lystdrevne menneske vil ofte blive beskrevet, ifølge en religiøs dogmatisk moral, som skyldig i dødsynden Avaritia bedre kendt som griskhed.

Joeh - da jeg skrev det kiggede jeg på http://en.wikipedia.org/wiki/Id,_ego,_and_super-ego, og det var "uncoordinated instinctual trends", der sprang i øjnene.

:o)

Jeg forstår dog ikke helt, hvorfor du bruger så meget energi på at udrede dette. Jeg antager, at min hensigt var klar: jeg tager det fulde ansvar for de ændringer jeg (via CIBERs arbejde i DS) har været med til at definere ... selvom jeg i dine øjne er "er nogle grådige lovbrydere, der burde straffes for deres forbrydelser mod den danske stat og folk. "

Jeg ville ønske, at IBM gjorde det samme (tog ansvar for de ting, der har godkendt i DS) i stedet for at tude løs, som det skete i ComputerWorld i sidste uge.

Din udtalelse fik mig dog til at tænke på noget, som jeg engang fik smidt i hovedet af Pamela Jones fra Groklaw:

"You harmed us and our families. You harmed the public, and you will have to live with that
judgment from us."

http://www.groklaw.net/comment.php?mode=display&sid=20090427113709957&ti...+really+believe+that&type=article&order=&hideanonymous=0&pid=753803#c753808

:o)

  • 0
  • 0
Jarle Knudsen

@ Henrik Jensen & JLS

Jeg har på intet tidspunkt påstået at mine tal er 100% korrekte. Jeg har også skrevet at dersom I ikke var enige om, var I velkommen at komme med de korrekte størrelser.

Det har vi ikke set endnu.

Jeg er overbevist at specielt Jesper er mere end kvalificeret til at levere nøjagtige tal på hvor meget OOXML fylder totalt (jeg mener samtlige OOXML + "det løse").

Spørgsmålet er: er det noget grund til at han ikke ønsker at oplyse det?

PS. God morgen :O)

  • 0
  • 0
Jesper Lund Stocholm Blogger

Godmorgen, Jarle,

Jeg har på intet tidspunkt påstået at mine tal er 100% korrekte.

Skal vi så ikke lade den ligge dér, og så kommenterer jeg ikke videre på dine tal? Jeg skal gerne give mit besyv med, men når du ikke kan forklare dine tal, så giver det ikke meget mening.

Jeg er overbevist at specielt Jesper er mere end kvalificeret til at levere nøjagtige tal på hvor meget OOXML fylder totalt (jeg mener samtlige OOXML + "det løse").

Spørgsmålet er: er det noget grund til at han ikke ønsker at oplyse det?

Wow ... konspirationsteorier - og klokken er ikke engang 9.

Jeg giver dig gerne mit officielle syn på sideantallet:

[b]OOXML er på 6000 sider.[/b]

I de 6000 sider kan du smide alt du har nævnt ovenfor.

[b]Begrundelsen:[/b]

ECMA-376 er på 6000 sider
ECMA-376 = DOCX/XLSX/PPTX
ISO/IEC 29500:2008 er på 6000 sider.

Men ISO/IEC 29500:2008 er så viseligt indrettet, at den inkluderer ECMA-376. Ønsker man at implementere ECMA-376 understøttelse, kan man altså tage fat i ISO/IEC 29500:2008 og implementere Part 1,2 og 4. Ønsker man at være lidt mere fremme i skoen og implementere ISO/IEC 29500:2008 strict, så kan man "nøjes" med Part 1+2.

  • 0
  • 0
Jarle Knudsen

konspirationsteorier - næææ... har ikke fået min kaffe endnu :O)

Ret skal være ret:
ISO OOXM - 6.549 sider,
ECMA OOXML - 6.045 sider

iflg. Wikipedia. Ikke helt 25k eller 30k som jeg har skrevet men stadig rigtig mange sider at tygge sig igennem.

Bare for at sætte ting i et perspektiv:

http://blog.janik.cz/archives/2007/07/18/T18_02_54/

Det skal ganges med 2 (ECMA og ISO)

Tilsvarende fylder ODF "867 pages long and achieves the same goals." (iflg. Wikipedia) - altså en halv perm...

Min pointe er mens mastodonter som IBM, SUN, Microsoft mm. hyrer blot flere udviklere, kan størrelsen alene være en for høj indgangsbarriere for små og mellemstore virksomheder. Også selv om man fokusere kun på ISO OOXML.

ODF virker bare som en mere overkommelig standard.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Jarle,

Tilsvarende fylder ODF "867 pages long and achieves the same goals." (iflg. Wikipedia) - altså en halv perm...

Reelt befinder "nirvana" sig imellem de to ekstremer repræsenteret ved OOXML og ODF. OOXML er på visse områder overspecificeret og flere steder gentages information. Tilsvarende er ODF underspecificeret og det er i mine øjne mere reglen end undtagelsen, at man kan læse alt ud af spec (og ikke skal have fat i OOo for at lave test-filer).

Eksemplet jeg brugte tidligere på den nyt database dokumenttype i ODF 1.2 er faktisk ret repræsentativ for ODF. Afsnittet er reelt blot en beskrivelse af elementer og attributter - og her kunne jeg i den grad ønske, at der var en masse sider med forklaringer til, hvad det dog skal bruges til.

ODF virker bare som en mere overkommelig standard.

Ja, det har du ret i. Men jeg er stærkt tvivlende overfor, om du ville mene det samme, hvis du fx skulle implementere grafikformatet i ODF. Eller matematisk information i tekst-dokumenter (MathML/OMML).

Derudover er der en detalje, som lige skal med. Du nævner selv IBM, Google, Sun, Microsoft og siger, at små virksomheder ikke kan hamle op med dem. Det har du jo ret i - men små virksomheder har typisk heller ikke behov for at implementere hele standarden. Her implementerer man jo små subsets af formaterne i regneark, skabeloner for breve etc. Det er min erfaring (ikke blot "påstand"), at med disse usecases er der ikke den store forskel på at implementere ODF eller OOXML.

  • 0
  • 0
Henrik Jensen

Tilsvarende fylder ODF "867 pages long and achieves the same goals." (iflg. Wikipedia) - altså en halv perm...

Det må så være ODF 1.0 eller 1.1 der hentydes til. ODF 1.0/1.1 indeholder blandt andet ikke nogen specifikation af formler. Så den kan da kun dække samme mål hvis målet ikke er at have fuld åbenhed og interoperabilitet på formler. ODF 1.2 fylder p.t. ca. 1260 sider inklusiv specifikation af formler

Min pointe er mens mastodonter som IBM, SUN, Microsoft mm. hyrer blot flere udviklere, kan størrelsen alene være en for høj indgangsbarriere for små og mellemstore virksomheder. Også selv om man fokusere kun på ISO OOXML.

Det er klart der vil altid være en grænse for hvor meget en lille spiller på markedet kan håndtere, men det gælder jo også for ODF. Sådan noget som KOffice har jo hele tiden halset efter OpenOffice.org og der er stadig dele af ODF 1.0 som ikke er implementeret i KOffice i dag

Og jo min fornemmelse er også at ECMA-376 1st. Edition er en større opgave at implementere end ODF da den indeholder fuldt bagudkompatibilitet med tidligere MS Office formater. Men jeg tror ikke at man kan bruge forholdet mellem antal sider til noget som helst. Det er klart at læse 6000+ sider tager længere tid end at læse 1260 sider, men langt det meste tid benyttes altså på implementeringen og ikke på at læse og der er der mange andre faktorer der spiller ind såsom f.eks. præcisionen (utvetydigheden) i standarden, hvor godt at standarden står alene (uden behov for at slå op i eksterne standarder + kildekode), er der eksempler og illustrationer for dem der finder hjælp i den slags m.v.

Det falder også tilbage på et af de spørgsmål jeg stillede tidligere, og hvor du forøvrigt behændigt undlod at svare på et eneste, nemlig er Microsoft Office binære formater på 850 sider nemmere at implementere end ODF 1.2 på 1260 sider?

Hvis jeg selv skal svare på det så er mit gæt et nej.

Er Microsoft Office binære formater på 850 sider nemmere at implementere korrekt end ECMA-376 1st. edition på 6000+ sider?

Igen hvis jeg selv skal svare på det så er mit gæt faktisk at nej det er den ikke, af netop af nogle af de årsager jeg tidligere nævnte omkring præcision, utvetydighed og muligheden for at stå alene.

  • 0
  • 0
Niels Elgaard Larsen

==

men små virksomheder har typisk heller ikke behov for at implementere hele standarden. Her implementerer man jo små subsets af formaterne i regneark, skabeloner for breve etc.

Ja, når man skal generere dokumenter.

Men når man modtager dokumenter fra andre parter, er man nødt til at implementere meget mere af standarden. Det er derfor, det er et mareridt med MSOOXML's mange varianter af datoer, regneregler, formater osv.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Niels,

Men når man modtager dokumenter fra andre parter, er man nødt til at implementere meget mere af standarden.

Enig :o)

Det er derfor, det er et mareridt med MSOOXML's mange varianter af datoer, regneregler, formater osv.

Hvilke "mange varianter" er det du hentyder til? OOXML understøtter to "epocs" - ODF understøtter en uendelighed at "epocs" (og reelt er det blot et spørgsmål om at vælge et sted at starte med at tælle). OOXML understøtter to måder at regne med datoer på - det samme gør ODF.

"Formater" - hvad mener du her?

  • 0
  • 0
Jakob Damkjær

Som du måske har anet så er der en del forskel på din mening om lødigheden af det bang up job DS har gjort og så min mening om samme.

Jeg er bare glad for at jeg i det mindste forsøger at undgå at gøre skade.

Men jeg har en underfundig form for halvlunken interesse i med hvor stor energi du forsvare et bundkorupt firma som alle ved vil lave en "udvid korrumper og udsluk" strategi hvis office penge koen får en real konkurent.

Et firma som allerede har taget røven på store dele af IT branchen med den snedigt udtænkte OS/2 luskemanøvre og som der nok stadig er en del firmaer der gerne ville se en dag hvor de kan gengælde den "store tjeneste" ms gjorde ved at snigløbe hele showet med win95.

Fool me once - shame on you - fool me twice - shame on me.

ms har jo ingen troværdighed tilbage på den front så jeg under mig fra tid til anden, når jeg har et ledigt øjeblik, over hvad bevæg grunden kunne være for dem der står tilbage på skansen midt på den landsdel af tillid der blev offer for microsofts brændtejords taktik.... og det eneste svar jeg til stadighed kan komme til er avaritia...

Men lad det nu ligge der er ingen grund til at diskutere, for der er intet at tilbage at diskutere...

For hvis man skulle kunne tro på at ms holder nogen af de løfter de har kommet med skal man ignorere årtiers empiri/fakta.

HVIS der nogensinde kommer et ISO ooxml baseret mso så kan man diskutere sagen igen. Men indtil det er efterprøvet FAKTA så er det eneste man kan tale om er løfter fra et firma der aldrig har holdt ord og det er faktisk ret ufrugtbart. Samtidigt er office som det sælges idag et de fakto proprietærformat ikke et standartbaseret format (nej dem der godkendte den første version af ooxml er ikke et standartorgan, det er en gummistempel organisation der er til salg for ussel mammon).

Så hele diskussionen er 100% meningsløs eftersom der realt set kun er et standartformat for office dokumenter og det er ODF. Det har sine problemer men det er et standartformat der kan implementeres og er blevet implementeret. Det er iso ooxml ikke idag.

Når iso ooxml bliver implementeret og udbredt så kan det være på sin plads at tage diskussionen op igen men pt er den fuldstændig nyttesløs.

  • 0
  • 0
Niels Elgaard Larsen

Hej Jesper.

Jeg mente at ODF ikke introducerer nye datoformater.

Med OOXML ville jeg ikke vide om fx 1900 var et skudår, når jeg skulle parse en dato. Jeg prøvede hurtigt at slå det op og Google det inden jeg svarede dig, men det lykkedes ikke på den begrænsede tid, jeg kunne afse til det. Og det illustrerer jo problemet med en 6000 siders standard.

  • 0
  • 0
Henrik Jensen

Men jeg har en underfundig form for halvlunken interesse i med hvor stor energi du forsvare et bundkorupt firma som alle ved vil lave en "udvid korrumper og udsluk" strategi hvis office penge koen får en real konkurent.

Når der nu står en organisation derude og skal vælge mellem om de skal vedblive med at benytte MS Office eller om de skal vælge en af alternativerne hvilken af følgende to situationer stiller så denne organisation bedst i forhold til at kunne foretage et frit valg:

1) Eksisterende dokumenter fra MS Office kan indlæses i den nye kontorpakke

2) Eksisterende dokumenter fra MS Office kan ikke indlæses i den nye kontorkappe

Jeg kan personligt ikke se andet end at situation 1 stiller organisationen bedst. Hvad er din holdning til dette?

Så konklusionen på det må være at hvis andre kontorpakker kan læse dokumenter fra MS Office så er det med til at øge muligheden for at foretage frie valg.

Det leder så til det næste spørgsmål. Når nu det altså gavner de alternative kontorpakker at de kan læse filer fra MS Office hvilken af følgende to situationer stiller dem så bedst i forhold til dette

1) MS Office filer benytter et lukket format, tidligere slet ikke tilgængeligt, nu tilgængeligt med i en specifikation som ved første øjekast ikke ser særlig nem ud at implementere

2) MS Office filer benytter et åbent format, som de ikke længere har 100% kontrol over, og hvor de har udstukket garantier for at man frit kan implementere.

Jeg vil mene det er situation 2 som er bedst i den situation. Hvad er din holdning til dette?

Så jeg har svært ved at se hvordan at udviklingen på nogen måde har været dårlig. Men det betyder selvfølgelig ikke at vi er ved endemålet.

Samtidigt er office som det sælges idag et de fakto proprietærformat ikke et standartbaseret format (nej dem der godkendte den første version af ooxml er ikke et standartorgan, det er en gummistempel organisation der er til salg for ussel mammon).

Det allervigtigste punkt ved at være åben det er da at specifikationen er tilgængelig, at den kan implementeres af andre og at de kan gøre det gratis (altså uden betaling af licens). Det er opnået med ECMA-376 1st. Edition.

Det næste punkt er så indflydelsen, her synes jeg at forskellene på OASIS og ECMA er minimale. ISO er da at foretrække men det gælder jo både for OOXML og ODF. Så jo vi vil da helst at kontorpakkerne benytter en ISO godkendt version af ODF samt OOXML og at fremtidig vedligeholde af disse to standarder ligger hos ISO, og der tror jeg også vi kommer til, men det sker bare ikke over en enkelt weekend.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Niels,

Jeg mente at ODF ikke introducerer nye datoformater.

Det gør OOXML heller ikke.

Med OOXML ville jeg ikke vide om fx 1900 var et skudår, når jeg skulle parse en dato. Jeg prøvede hurtigt at slå det op og Google det inden jeg svarede dig, men det lykkedes ikke på den begrænsede tid, jeg kunne afse til det. Og det illustrerer jo problemet med en 6000 siders standard.

Undskyld - men synes du ikke, at det ville være en bedre idé at slå op i selve standarden i stedet for på Google?

Jeg lavede en søgning på "1900" i ECMA-376, og efter 5 (bogstaveligt talt!) sekunder havde jeg fundet dette:

[b]Fra ECMA-379 s. 2523[/b]
For legacy reasons, an implementation using the 1900 date base system shall treat 1900 as though it was a leap year. [Note: That is, serial value 59 corresponds to February 28, and serial value 61 corresponds to March 1, the next day, allowing the (non-existent) date February 29 to have the serial value 60. end note] A consequence of this is that for dates between January 1 and February 28, WEEKDAY shall return a value for the day immediately prior to the correct day, so that the (non-existent) date February 29 has a day-of-the-week that immediately follows that of February 28, and immediately precedes that of March 1.

  • 0
  • 0
Niels Elgaard Larsen

Jesper:
> Fra ECMA-379 s. 2523

> Standard ECMA-379 Test Method for the Estimation of the Archival Lifetetime of Optical Media
Du mener 376-2 ?

Du må have en hurtig maskine, hvis du kan loade et 6000 siders dokument og søge i det på 5 sekunder.

Men det er da noget klamp:

Og på samme side står:

==
* In the 1900 date base system, the lower limit is January 1, -9999 00:00:00, which has serial value -
4346018. The upper-limit is December 31, 9999, 23:59:59, which has serial value 2,958,465.9999884.
The base date for this date base system is December 30, 1899, which has a serial value of 0.

  • In the 1900 backward compatibility date-base system, the lower limit is January 1, 1900, 00:00:00, which
    has serial value 1. The upper limit is December 31, 9999, 23:59:59, which has serial value
    2,958,465.9999884. The base date for this date base system is December 31, 1899, which has a serial
    value of 0.

  • In the 1904 backward compatibility date-base system, the lower limit is January 1, 1904, 00:00:00, which
    has serial value 0. The upper limit is December 31, 9999, 23:59:59, which has serial value
    2,957,003.9999884. The base date for this date base system is January 1, 1904, which has a serial value
    of 0.

A serial value outside of the range for its date base system is ill-formed.
[Note: The 1900 date-base system is the preferred system to be used by applications when converting serial
values to dates. The use of the 1900 backward compatibility or 1904 backward compatibility date-base system
should be avoided. end note]
The date-base system is recorded in the Workbook part's XML by the presence or absence of the
dateCompatibility and date1904 attributes of the workbookPr element.

==

Så der er ikke to, men tre måder at regne datoer på.
Og den forkerte måde er den foretrukne.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Niels,

> Standard ECMA-379 Test Method for the Estimation of the Archival Lifetetime of Optical Media
Du mener 376-2 ?

Dammit - jeg mente "ECMA-376, 1st Ed".

Du må have en hurtig maskine, hvis du kan loade et 6000 siders dokument og søge i det på 5 sekunder.

Det er blot Acrobat Reader. Den har to måder at søge på. Den ene er en sekventiel gennemsøgning af alle sider og den anden (der har sin egen søgedialog) gør det noget mere effektivt. Det tog et par sekunder at lave søgningen samt 5 sekunder at vurdere hvilket resultat jeg skulle bruge. Min maskine er en Lenovo T61p. Det er bestemt ikke mit generelle indtryk, at den er super hurtig :o).

Så der er ikke to, men tre måder at regne datoer på.
Og den forkerte måde er den foretrukne.

De ting du nævner er fra ISO-udgaven af OOXML. Her er der ganske rigtigt tilføjet et nyt foretrukket "basissystem" (epoc). I ECMA-376-1 var der to i alt. Eneste forskel på datoformaterne er intervallet for valide datoer samt dets basisdato. I ODF hedder dette "NULL DATE".

Så der er ikke to, men tre måder at regne datoer på.

Jeps - og i ODF er der en uendelighed. Hvad vil du foretrække?

Og den forkerte måde er den foretrukne.

Det er ikke korrekt. Der står (og du citerer det jo selv):

"[Note: The 1900 date-base system is the preferred system to be used by applications when converting serial values to dates. The use of the 1900 backward compatibility or 1904 backward compatibility date-base system should be avoided. end note]".

Jeg synes ærligt talt, at dine argumenter er ret tynde - de tyder mest af alt på, at du ikke har sat dig ret godt ind i emnet inden du kontant konkluderede "det illustrerer jo problemet med en 6000 siders standard."

(undskyld mig)

  • 0
  • 0
Henrik Jensen

Med den historie benævnte firma har, forstår jeg ikke at du vælger situation 2.

Medmindre, du forventer EU sagsøger Microsoft, når de løber fra løftet :-)

Det er da lige meget med EU i denne sammenhæng. Det handler om hvordan jeg står hvis Microsoft sagsøger mig for at implementere OOXML, og der står jeg rigtig godt.

Samtidigt hvor mange gange har Microsoft brugt deres patenter offensivt relativt til f.eks. en virksomhed som IBM? Men du stoler mere på IBM når de siger at de ikke vil bruge deres patenter offensivt imod f.eks. Linux? Adobe har også tidligere benyttet deres patenter offensivt, men du stoler også på deres erklæring om at du frit kan implementere PDF?

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Niels,

Øhm - er du helt med på, hvad vi snakker om?

Du har selv citeret følgende:

[b]Niels fra OOXML:[/b]
* In the 1900 date base system, the lower limit is January 1, -9999 00:00:00, which has serial value -
4346018. The upper-limit is December 31, 9999, 23:59:59, which has serial value 2,958,465.9999884.
The base date for this date base system is December 30, 1899, which has a serial value of 0.

[b]Niels fra OOXML:[/b]
[Note: The 1900 date-base system is the preferred system to be used by applications when converting serial values to dates. The use of the 1900 backward compatibility or 1904 backward compatibility date-base system should be avoided. end note]

"Leap-year-bug" har intet med hvilken epoc (dato-system) dokumentet anvender. Datosystemerne beskriver blot valide datointervaller samt fastslår "null date".

  • 0
  • 0
Niels Elgaard Larsen

"Leap-year-bug" har intet med hvilken epoc (dato-system) dokumentet anvender. Datosystemerne beskriver blot valide datointervaller samt fastslår "null date".

Du citerede jo selv

For legacy reasons, an implementation using the 1900 date base system shall treat 1900 as though it was a leap year.

Så Microsoft har altså puttet fejlagtige datoer i OOXML.

Som udvikler bryder jeg mig altså ikke om, at jeg også lige skal kunne håndtere et ekstra format, hvor jeg lige skal læse 6000 sider for at finde ud af, at jeg ikke bare kan trække to datoer fra hinanden for at finde ud af hvor mange dage, der er imellem.

Du fandt det på 5 sekunder fordi du har deltaget i standardarbejdet og vidste, at du skulle søge efter årstallet 1900.
Vi andre er nødt til at kigge standarden igennem for overraskelser.

CEILING er en anden overraskelse.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Niels,

Jeg synes altså, at du ser et problem med det formål at se et problem.

Det er klart, at hvis du mener, at man som udvikler ikke nødvendigvis skal kigge i specifikationen for at implementere understøttelse, så har du ret - det er ikke logisk, at man i nogle tilfælde skal behandle 1900 som skudår.

Men hvis du som os andre mener, at det nok er en god idé at kigge lidt i specifikationen før man sætter sig til tasterne, så er det altså ganske nemt at finde.

Afsnittet om SpreadsheetML har søreme et afsnit, der omhandler formler (ISO afsnit 18.17). Så hvis du skal implementere formler i OOXML (som man jo skal for at kunne beregne på celler), så kunne man jo forestille sig, at det var et godt sted at kigge - synes du ikke? I dette afsnit er der et delafsnit, der omhandler behandling af datoer. I TOC for SpreadsheetML er dette overordentligt nemt at se, for der står simpelthen:

*18.17 Formulas
**18.17.1 Introduction
**18.17.2 Syntax
(...)
**18.17.3 Error values
**18.17.4 [b]Dates and times[/b]

Her kan du se, at det eneste du behøver at læse er 3 sider omkring netop dette.

Jeg synes, at der er en verden til forskel på dette og så de 6000 sider du mener du skal pløje igennem.

Hint: Indholdsfortegnelsen er et godt sted at kigge.

Ovenstående skridt er i øvrigt nogen jeg vil tro man ville lave - uanset at jeg via ISO-arbejdet ved, at der er noget, der hedder "legacy-leap-year-bug" og at tallet er 1900.

Du nævner også "CEILING", men jeg forstår igen ikke, hvorfor du mener, at det er et problem. Funktionen er defineret i 18.17.7.33, og på den side står præcist, hvordan den opfører sig.

Mener du igen, at man skal kunne implementere X uden at kigge i spec? I ODF 1.2-2 (OpenFormula) er CEILING (6.16.1) også specificeret (selvfølgelig).

CEILING er jo basalt en funktion, der som input tager et tal og en signifikans og afrunder tallet. Men i OpenFormula er der også en tredje parameter, der hedder "number mode". Hvordan vil du - uden at skulle kigge i specifikationen - kunne afgøre, hvad denne parameter bruges til? Skal du også her pløje dig igennem alle 1200 sider i ODF 1.2?

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