Microsoft: OSL har slet ikke testet en åben standard

Foreningen af Open Source-leverandører i Danmark har testet interoperabilitet mellem ODF-implementeringer, der ikke bygger på nogen åben standard. Det siger Microsoft.

Alle kneb gælder, når de danske it-ordførere forud for dagens møde med Helge Sander skal påvirkes i retning af enten ODF eller OOXML. Ligesom i amerikanske præsidentvalgkampe, er negativ omtale af modparten et af de våben, der nu anvendes i dokumentformatkrigen.

I går offentliggjorde Foreningen af Open Source-leverandører (OSL) en rapport, der viste fuld interoperabilitet mellem seks implementeringer af ODF-formatet, hvorfor OSL beskyldte Konkurrencestyrelsens rapport for at tale usandt om manglende interoperabilitet i ODF-lejren.

Allerede et par timer senere skød OOXML-lejren personificeret ved Microsofts Jasper Boisen rapporten ned ved at kalde det snyd, når rapporten dybest set tester, om OpenOffice er interoperabel med OpenOffice.

I dag kommer så endnu et angreb på rapporten.

»Hvis du ser nærmere på OSL's rapport, står det klart, at de slet ikke har testet programmer baseret på en åben standard. Alle programmerne anvender en version af ODF, som OASIS arbejder på, men som ikke er ratificeret.,« siger Jasper Boisen, teknologidirektør i Microsoft Danmark, til Version2.

Ifølge Jasper Boisen anvender alle de fire inkarnationer af OpenOffice, som OSL har testet, en draft version af ODF (ODF 1.2 draft), som hverken er en OASIS eller en ECMA-standard ? for slet ikke at tale om ISO-standard.

Han kalder rapporten sjusk og hastværk og mener derfor, at den ikke kan bruges til noget som helst.

»Konkurrencestyrelsens rapport var jo hverken, hvad OSL havde håbet på eller drømt om. Med ODF-rapporten fra i går driver de politik på et lavt plan ved at teste openoffice mod openoffice,« fortsætter Jasper Boisen.

Han hæfter sig ydermere ved, at politikerne i den oprindelige beslutning ved navn B103 specifikt nævner, at der skal være en organisation ind over åbne standarder til at blåstemple dem.

»I det her tilfælde er standarderne slet ikke ratificeret af nogen,« siger han.

Jasper Boisen afviser, at noget lignende gør sig gældende for Microsofts implementering af OOXML.

»Det her lugter langt væk af, at Sun og IBM først laver et produkt og derefter en dokumentstandard. Ja faktisk er det endnu værre, for her er et produkt baseret på noget, der endnu ikke er en standard. Vi mener, den rigtige rækkefølge må være: først standard, derefter produkt. Det giver alle lige muligheder, og det er sådan vi gør med OOXML,« siger han.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (63)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Emil Jensen

Ja man kan diskutere tingene til langt ud på natten, men summa summarum er at OOXML er et lorteformat der burde have været skrottet for lang tid siden, og det ved alle fornuftige mennesker der kender til de to standarder her.

  • 0
  • 0
Christian Nobel

Jasper Boisen afviser, at noget lignende gør sig gældende for Microsofts implementering

Nåeh ja for hvordan er det liiige med en referenceimplementation der understøtter ISO OOXML?

Nå men Hr. Bojsen mener åbenbart at det er rigtig smart ide at rette jagtgeværet ned mod sin egen fod.

Vi mener, den rigtige rækkefølge må være: først standard, derefter produkt.

Nå nu er han også gået igang med den sjove tobak - det var dog den til dato mest absurde udtalelse fra spindoktor Bojsen.

Sporer man panik før lukketid hos Hr. Bojsen?

/Christian

  • 0
  • 0
Klaus Skelbæk Madsen

Øhm, ifg. http://www.ecma-international.org/publications/standards/Ecma-376.htm blev den første version af OOXML standarden publiceret i december 2006.

Ifg. Wikipedia (http://en.wikipedia.org/wiki/Microsoft_Office_2007) var Office 2007 tilgængelig for volume license kunder fra november 2006.

Så der må vel gælde det samme for første version af OOXML, som der gælder for ODF 1.2.

  • 0
  • 0
Morten Juhl-Johansen Zölde-Fejér

Det er sådan set lige meget om anklageren følger samme standard som den anklagede - anklagen er vel alligevel noget, man skal forholde sig til.
Lommetyven bliver ikke mindre tyv af, at han anklager en skatteunddrager, men sidstnævnte bliver det heller ikke mindre af, at det er en tyv, der anklager. De skal bare lette sig og have orden i sagerne. Som så ofte før kan vi bare gentage: Hvis al den energi var brugt på implementering...

  • 0
  • 0
Martin Bøgelund

Allerede et par timer senere skød OOXML-lejren personificeret ved Microsofts Jasper Boisen rapporten ned ved at kalde det snyd, når rapporten dybest set tester, om OpenOffice er interoperabel med OpenOffice.

Det er tankevækkende at Microsoft, som søsatte begrebet "de facto standard" for at forsvare at deres kontorpakke ikke brugte en vedtagen dokumentstandard, nu åbenbart finder det problematisk, at OpenOffice-implementereingen af ODF er blevet en "de facto standard".

  • 0
  • 0
Henrik Jensen

Nåeh ja for hvordan er det liiige med en referenceimplementation der understøtter ISO OOXML?

Der har aldrig været en referenceimplementation af ODF og der kommer det formentligt heller aldrig. Der har aldrig været en referenceimplementation af OOXML og der kommer det formentligt heller aldrig.

  • 0
  • 0
Henrik Jensen

Det er tankevækkende at Microsoft, som søsatte begrebet "de facto standard" for at forsvare at deres kontorpakke ikke brugte en vedtagen dokumentstandard, nu åbenbart finder det problematisk, at OpenOffice-implementereingen af ODF er blevet en "de facto standard".

Man kunne jo få den tanke at de har lært noget :-)

  • 0
  • 0
Dennis Skovborg Jørgensen

"Ifølge Jasper Boisen anvender alle de fire inkarnationer af OpenOffice, som OSL har testet, en draft version af ODF (ODF 1.2 draft), som hverken er en OASIS eller en ECMA-standard – for slet ikke at tale om ISO-standard."

Er det ikke irrelevant? Testen gik på import af et dokument genereret i OOo 2.3. Skriver den ikke ODF 1.1?

Man kunne selvfølgelig ønske sig en test af om de stadig kan skrive ODF i et format som OOo 2.3 kan læse, men mon ikke det også går uden problemer?

  • 0
  • 0
Christian Nobel

Der har aldrig været en referenceimplementation af ODF og der kommer det formentligt heller aldrig.

Åh hvor typisk, vend den lige 180 grader - suk.

Det kan godt være der ikke er en officiel reference implementation af ODF, men muligheden er væsentlig nærmere, bla. pga. den formastelige fælles kodebase.

Der har aldrig været en referenceimplementation af OOXML og der kommer det formentligt heller aldrig.

Nej, og så er det rigtig morsomt, at dem der givetvis laver en referenceimplementation af ODF gør det som et OSS projekt, som alle andre kan benytte, hvorimod der som du trods alt selv indrømmer, [b]aldrig kommer en referenceimplementation af OOXML[/b], og hvis det endelig af en eller anden uransagelig grund ville ske, så ville det blive en black-box.

Det i sig selv er nok til at OOXML (af spindokter Bojsen meget underholdende udtalt som Open XML - haa.) hurtigst muligt kun skal blive en glemt parantes i IT historien.

Og før du og Jesper ævler videre med jeres hadefulde IBM speak, så skal man ikke glemme på at IBM (og andre ODF leverandører) på ingen måde kan bruge ODF som brik i et vendor-lock-in spil, men MS kan med OOXML og dets understøttelse af alt muligt proprietært MS ragelse.

/Christian

  • 0
  • 0
Henrik Jensen

Åh hvor typisk, vend den lige 180 grader - suk.

Nej det handler bare om at benytte ordet referenceimplementation korrekt.

Mange har nemlig den opfattelse at OpenOffice.org er en referenceimplementation af ODF men det er den bestemt ikke. Selv Rob Weir siger at det ikke er en referenceimplementation.

Den gang at Rob Weir fra IBM (co-chair i ODF TC) han brugte en stor del af sin tid på at skrive indlæg på sin blog om hvor dårligt at OOXML er, der var folk helt vilde med ham og citerede ham og linkede til hans blog hele tiden. Nu hvor han så er begyndt at beskæftige sig mere med ODF interoperabilitet og mindre med at svine OOXML til, og blandt andet kan finde på at skrive indlæg om at ODF interoperabiliteten kan forbedres og at OpenOffice.org ikke er en referenceimplementation o.s.v. så er stort set ingen interesseret i ham mere og ignorerer hvad han skriver.

Det er lidt ironisk at nu hvor han for alvor laver et arbejde der gavner ODF så glemmer mange folk ham. Han skal nok havde fundet den gamle stil frem igen med mindst et par indlæg om ugen der sviner OOXML og ISO til om ugen før at folk igen finder det interessant at læse hvad han skriver. Meget sørgeligt.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Jasper,

Vi mener, den rigtige rækkefølge må være: først standard, derefter produkt. Det giver alle lige muligheder, og det er sådan vi gør med OOXML,« siger han.

Helt ærligt - det er lidt noget pjat. Hvad vil du så karakterisere de ting I har puttet i OOXML i forbindelse med udviklingen af Office2010? Disse er jo ikke en del af IS29500.

JTC1/SC22 (der bla. vedligeholder C++) har det princip, at man ikke putter noget i standarden, der ikke er implementeret allerede. Det princip kommer vi sandsynligvis til at læne os op ad i SC34/WG4 også, så det er i høj grad "produkt før standard" for OOXML også.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Christian,

MS kan med OOXML og dets understøttelse af alt muligt proprietært MS ragelse.

Skægt - jeg anede ikke, at der i OOXML var understøttelse af "proprietært MS ragelse", men du har åbenbart noget information, som jeg (og i øvrigt resten af WG4) ikke har.

... og hvis du med "proprietært MS ragelse" skyder imod de såkaldte "compat-elements", så kan man med nøjagtig samme argument taget et hvilket som helst element/attribute i både ODF og OOXML og sige, at netop dette element/attributs eksistens understøtter "proprietært ragelse" - nemlig henholdvis Microsoft Office eller OOo 1.x .

... men det er jo noget ubrugeligt vås (sorry).

:o)

  • 0
  • 0
Jasper Bojsen

Jesper,

Jeg er helt enig med dig i, at i forbindelse med anvendelse af enhver standard, skal der være mulighed for innovation. Uden innovation, ingen fremgang, ingen merværdi til forbrugeren og ingen sund konkurrence.

Om rækkefølgen skal være produkt-standard, standard-produkt eller noget midt imellem, lader sig naturligvis ikke opsummere på en [i]one-liner[/i], så derfor jeg vil gerne uddybe hvad det er som ligger bag ovenstående citat, samt forsøge at tilføje nogle af de ord som ikke kom med i ”trykken”.

Jeg mener at det er problematisk, at alle nyere inkarnationer af OpenOffice anvender en … [i]skal vi kalde den [/i] … [b]mellemversion[/b] af ODF. Med andre ord en ODF version ikke er ratificeret af hverken OASIS eller ECMA og slet ikke ISO/IEC.

Jeg mener at det giver sig selv at nyere kontorpakker indeholder ny funktionalitet. Den udvikling er til gavn for alle. Men der er forskel på om en kontorpakke arbejder ud fra en standardiseret base og anvender [url=http://blogs.msdn.com/dmahugh/archive/2009/07/21/dii-workshop-mce-deep-d...] veldefineret mekanismer i standarden[/url] til at repræsentere ny funktionalitet, eller om hver ny version af en kontorpakken betyder, at der også kommer en ny hel eller halv version af filformatet. Sidstnævnte mener jeg indikerer, at processen omkring standarden og processen omkring udviklingen af et produkt er alt for tæt bundet sammen. Kort fortalt mener jeg, at den meget direkte indflydelse, som første og fremmest IBM og SUN har på ODF i OASIS, udfordrer åbenhen af ODF.

Mvh,
Jasper

  • 0
  • 0
Jesper Lund Stocholm Blogger

HEj Jasper,

Jeg mener at det er problematisk, at alle nyere inkarnationer af OpenOffice anvender en … skal vi kalde den … mellemversion af ODF. Med andre ord en ODF version ikke er ratificeret af hverken OASIS eller ECMA og slet ikke ISO/IEC.

Jeps - jeg er helt enig, og fraværet af kritik af dette er mildest talt ét af de bedste eksempler på hykleriet i debatten.

der er forskel på om en kontorpakke arbejder ud fra en standardiseret base og anvender veldefineret mekanismer i standarden til at repræsentere ny funktionalitet

Joeh ... men en udvidelse er nu engang en udvidelse - uanset hvor meget løbestift man putter på den (MCE). Den eneste forskel på dette ifht OOXML og ODF er, at der med OOXML rent faktisk er tænkt over måden at håndtere udvidelser på. I ODFs tilfælde har man været fuldstændig ligeglade med det (og det har i øvrigt givet ODF TC kompatibilitetsproblemer med ODF 1.2).

Rent faktisk er mekanismerne i OOXML til udvidelser så gode, at der er et pres langt ind i ODF TC for at få ODF til at adoptere en tilsvarende mekanisme (og nej, det er ikke kun fra Microsoft presset kommer).

PS: jeg anede ikke, at OSL havde testet OpenOffice.org-interoperabilitet med ODF 1.2 ... hvis det er rigtigt, er der vist efterhånden ikke meget kød tilbage på den "analyse".

:o)

  • 0
  • 0
John Foldager

Nu sidder jeg her og forsøger at følge op på alle de artikler og indlæg der er skrevet rundt omkring omkring OOXML og ODF. Jeg skal måske lige starte med at sige at jeg er medlem af OSL - ikke at jeg har været med til at udarbejde hverken test, dokumenter eller andet, men udelukkende fordi jeg støtter op omkring ODF. Hvorfor? Fordi det er et format som også små virksomheder kan implementere, hvorimod OOXML er alt for stort at implementere med mindre man har riiiiigtig meget tid til overs. Nå men... mit indlæg her er IKKE for at tale for eller imod nogen af formaterne... dét gør andre meget bedre. Mit indlæg er udelukkende for at kaste lidt lys over OSL's rapport som jeg læser den. Med mindre der er noget jeg har overset så ser det for mig ud til at alle indlæg til alle Version2's artikler (og også andre medier) taler om pærer og bananer. Nogle spørgsmål:

Spørgsmål 1: Hvor står der at OSL benytter en ikke-godkendt standard (som nogle refererer til er version 1.2)? Jeg kan kun se at OSL har benyttet sig af de samme dokumenter der blev lavet til test af Konkurrencestyrelsen for 1 1/2 år siden. Jeg formoder ikke at de dengang testede en version der ikke var godkendt... eller hvad?

Spørgsmål 2: Der er flere der skriver at det er snyd at OSL benytter flere forskellige applikationer som alle bygger på OpenOffice.org's kodebase. Dét kan jeg godt forstå at nogle vil synes er snyd hvis det var at de nævnte applikationer benyttede eksakt samme kode-base. Dét tror jeg dog ikke på, så med mindre der er nogen der kan henvise til hvilken version af OpenOffice.org's kodebase de forskellige applikationer benytter sååå...

Spørgsmål 3: Hvis nu de nævnte applikationer kan håndtere det endnu-ikke-godkendte ODF 1.2 format hvad så? Tjaa... for mig at se gør dét ikke den store forskel, for testen er udelukkende lavet med henblik på at LÆSE de dokumenter som blev lavet for 1 1/2 år siden; ikke for at SKRIVE i et ikke-godkendt format! Så hvor er det lige at snakken om ODF 1.2 kommer ind?

Jeg synes at både Jasper Boisen og Version2 bør uddybe deres artikler og kommentarer med flere facts så vi andre som ikke når deres/jeres kompetencer indenfor dette 'spændende' område kan læse - og - kommentere udfra de samme informationer, i stedet for at spørge/svare i øst og vest.

Jeg mener vi mangler artiklEN som forklarer hele denne sag og 'krig' i detaljer OBJEKTIVT set og med så mange relevante facts som muligt.

Beklager hvis der er fejl/mangler i mit indlæg, men som sagt så er dette blot som jeg ser 'emnet' ;o)

  • 0
  • 0
Henrik Jensen

eg kan kun se at OSL har benyttet sig af de samme dokumenter der blev lavet til test af Konkurrencestyrelsen for 1 1/2 år siden. Jeg formoder ikke at de dengang testede en version der ikke var godkendt... eller hvad?

Sådan har jeg også læst og forstået det. Der blev benyttet OpenOffice.org 2.3 i sin tid til at oprette dokumenterne og OOo 2.3 benyttede ikke ODF 1.2 og derfor er de testede dokumenter formentligt ODF 1.1.

for testen er udelukkende lavet med henblik på at LÆSE de dokumenter som blev lavet for 1 1/2 år siden; ikke for at SKRIVE i et ikke-godkendt format!

Det er faktisk en dimension som jeg ikke lige har tænkt over før du nu skriver det. Men det at OSL testen kun har gået ud på at læse nogle dokumenter udarbejdet i OpenOffice.org 2.3 i andre kontorpakker, illustrerer jo også blot endnu et sted hvor at OSL testen fraviger fra Devoteams analysearbejde og derfor blot underbugger at det at bruge OSL testen til at påvise at Devoteams rapport er usand giver ingen mening.

Det OSL testen viser er jo at et ODF dokument oprettet i OpenOffice.org det kan åbnes og indlæses i f.eks. Lotus Symphony. Testen påviser ikke om det også er tilfældet den anden vej rundt, altså at et ODF dokument kan oprettes i f.eks. Lotus Symphony og indlæses i OpenOffice.org. Som udgangspunkt er det selvfølgelig sandsynligt men på anden side ser vi også massere af kontorpakker som nogen gange er bedre til at læse og præsentere givne dokumentformater end de er til at skrive.

Jeg har intet sted i Devoteams rapport set at deres konklusioner er baseret udelukkende på at alle ODF dokumenter skal oprettes i OpenOffice.org og så skal de indlæses i andre kontorpakker.

Det vil sige hvis man sammenlinger Devoteams rapport og OSL testen så er der følgende forskelle

1) Devoteam har kigget bredere funktionelt. Selv om det ikke har været højeste prioritet har de også kigget på interoperabilitet i forhold til regneark og præsentation. OSL testen ser kun på interoperabilitet inden for tekstbehandlingsdelen

2) Devoteam har set på et større udvalg af kontorpakker. Det har vist allerede været debatteret rigeligt at OSL Testen er begrænset til et mindre sæt af kontorpakker som "tilfældigvis" alle oprindeligt er forks af OpenOffice.org kodedatabasen.

3) Devoteam har ikke begrænset deres analyse til at alle ODF dokumenter skal oprettes i OpenOffice.org og så skal de indlæses i andre kontorpakker, som OSL testen er begrænset til. Devoteam har også antaget et man skal kunne oprette ODF dokumenter i andre kontorpakker og f.eks. indlæse dem i OpenOffice.org

John, én ting der dog undrer mig i forhold til udsagnet om at OSL testen kun har gået ud på at læse og ikke skrive det er testen af ændringssporing (11.2). Hvis testen af ændringssporing har foregået udelukkende ved at lave nogle ændringer i OpenOffice.org og så åbne dokumentet og se at disse ændringer er markeret i anden kontorpakker uden evt. at godkende/afvise nogle af disse ændringer samt eventuelt tilføje ekstra ændringer for så at skrive dokumentet ned igen og sende det tilbage til OpenOffice.org, så mener jeg ikke at testen er særlig realistisk i forhold til anvendelsen af denne funktionalitet. Ændringssporing er netop en type funktionalitet hvor du normalt har gentagne udvekslinger frem og tilbage mellem kontorpakkerne.

  • 0
  • 0
Henrik Jensen

Spørgsmål 2: Der er flere der skriver at det er snyd at OSL benytter flere forskellige applikationer som alle bygger på OpenOffice.org's kodebase. Dét kan jeg godt forstå at nogle vil synes er snyd hvis det var at de nævnte applikationer benyttede eksakt samme kode-base. Dét tror jeg dog ikke på, så med mindre der er nogen der kan henvise til hvilken version af OpenOffice.org's kodebase de forskellige applikationer benytter sååå...

StarOffice 9 update 1 byggede på OpenOffice.org 3.0.1. Så denne StarOffice 9 update 2 som blev benyttet i OSL testen bygger i hvert fald også på minimum OpenOffice.org 3.0.1 hvis ikke nyere version

OpenOffice 3.0 Novell edition bruger kodebasen fra OpenOffice.org 3 i følge deres egen hjemmeside

NeoOffice 3.0 bruger kodebasen fra OpenOffice.org 3.0.1 ifølge Wikipedia

Alle tre har de selvfølgelig lavet lidt tilføjelser og forbedringer men jeg er ret overbevist om at det er på områder som ikke direkte har med fortolkningen og præsentation af ODF at gøre (altså brugergrænseflade, hjælp, makroer, API, plugins m.v.). Hvis der er tiltro til at OpenOffice.org 3+ repræsenterer ODF standarden korrekt hvorfor så sætte sig ned og ændre i den eksisterende implementation, velvidende at man så ikke længere vil være kompatible med den førende ODF kontorpakke?

Så at der er god interoperabilitet mellem ovenstående tre kontorpakker og OpenOffice.org det er an absolut no-brainer. Jeg tror næppe at de testere der har hjulpet OSL med testen har siddet ved hver testkørsel og sagt "wooow set det her virker også".

Så står vi tilbage med den svære kontorpakke at vurdere i form af IBM Lotus Symphony 1.3, for den bygger nemlig på den bedagede OpenOffice.org 1.1.4. Men da OSL testen jo bestod af tests på et funktionsloft af ofte anvendt funktionalitet, så formoder jeg at langt den største del af denne funktionalitet også var tilstede i OpenOffice.org 1.1.4. Men der er altså en reel chance for at en mindre del af den funktionalitet der er testet rent faktisk har været udvidet eller tilføjet af IBM og ikke blot er kopi af OpenOffice.org koden. Så er det store spørgsmål bare om udvidelsen er sket ved at læse og fortolke standarden eller ved at tage et lille kig i OpenOffice.org kildekoden

  • 0
  • 0
Martin Bøgelund

Jasper:

Jeg mener at det er problematisk, at alle nyere inkarnationer af OpenOffice anvender en … skal vi kalde den … mellemversion af ODF. Med andre ord en ODF version ikke er ratificeret af hverken OASIS eller ECMA og slet ikke ISO/IEC.

Jesper:

Jeps - jeg er helt enig, og fraværet af kritik af dette er mildest talt ét af de bedste eksempler på hykleriet i debatten.

Kom igen ?!?

Hvorfor er det problematisk? Hvori består hykleriet? Og har I ikke netop serveret kritikken, så I ikke kan påkalde jer dens fravær?

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Martin,

Hvori består hykleriet?

Det er hyklerisk, fordi det udstiller den totalt manglende evne/lyst til at gribe i egen barm og kritisere fx OOo for deres handlemåde. At OOo som default produktionsformat anvender en "preliminary draft" af ODF er direkte skadende for ODF-miljøet og det tvinger samtlige andre ODF-læsende applikationer til at halse efter OOo for i det mindste at kunne læse de dokumenter OOo danner.

Jeg synes, at det er fint at OOo leger med draft-udgaver af ODF - det er jo det drafts er lavet til. Men det er en idiotisk beslutning at bruge det som default dokumentformat - for det ødelægger miljøet omkring ODF.

Måske kan du huske Rob Weirs indlæg om Excels ODF-understøttelse

http://www.robweir.com/blog/2009/05/follow-up-on-excel-2007-sp2s-odf.html

http://www.robweir.com/blog/2009/05/update-on-odf-spreadsheet.html

Hvis Rob Weir ikke havde gået ind i OOo og manuelt ændret dokumentformatet fra ODF 1.2 til ODF 1.1, så havde resultatet været nøjagtigt det samme som for Excel. Derfor ville der have været lige så mange røde felter for OOo, og det er naturligvis et kæmpe problem - ganske som at det er et problem for Excel.

Det er hykleri, når det eneste man hører fra "jer" (generelt betragtet) er småfesne kommentarer om, at "det er da også træls", når fx jeg pointerer disse ting.

Det er hykleri, når OSL og andre bruger enorme resourcer på at kæmpe imod OOXML i "den gode standards tjeneste" - når der mangler ganske mange ting i ODF, før den på alle punkter kan kaldes en "god standard".

Det er hykleri, for den manglende selvkritik udstiller på det klareste, at OSL ikke ønsker "gode standarder" - de ønsker blot ODF og ikke OOXML.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Henrik,

Så står vi tilbage med den svære kontorpakke at vurdere i form af IBM Lotus Symphony 1.3, for den bygger nemlig på den bedagede OpenOffice.org 1.1.4.

Det er faktisk lidt interessant - altså hvilken OOo Lotus Symphony er bygget på. For Lotus Symphony har jo også understøttelse for OOXML - og den var altså ikke en del af OOo 1.1.4 .

Derfor er status jo lige nu, at der (for de store leverandører) er ved at komme OOXML-understøttelse i disse programmer:

Microsoft: Microsoft Office
Apple: iWorks/TextEdit/iPhone
Corel: Word Perfect
Google: Google Docs (*)
Sun/ORACLE: OOo
IBM: Lotus Symphony
(øh?): NeoOffice

Alle disse applikationers OOXML-understøttelse har forskellige kodebaser, så det er sgu da en interoperabilitets-test, der sparker røv - og får OSLs "analyse" til at ligne en fristil fra folkeskolen.

Det bliver faktisk utroligt spændende at se, hvordan det spænder an ... og om det rent faktisk kan lade sig gøre at lave god interop på baggrund af OOXML - og forskellige kodebaser.

:o)

(*) Jeg er ikke helt sikker på, hvad Google Docs OOXML-understøttelse er baseret på.

  • 0
  • 0
Michael Rasmussen

Hej Jesper,

Du har glemt en: Abiword.

Personligt synes jeg dens understøttelse af OOXML, er bedre end OOo 3.1. Seneste release indeholder denne spændende bemærkning i release notes:

Make sure the Office Open XML exporter writes out valid documents

Har du testet udsagnet?

  • 0
  • 0
Henrik Jensen

Det er faktisk lidt interessant - altså hvilken OOo Lotus Symphony er bygget på. For Lotus Symphony har jo også understøttelse for OOXML - og den var altså ikke en del af OOo 1.1.4 .

Jeg har selv undret mig meget over det selvsamme.

IBM Lotus Symphony 1.3 som var den første version med OOXML understøttelse (delvis) blev jo først frigivet for 2-3 måneder siden.

Fra og med IBM Lotus Symphony 2, som jeg har set i en roadmap skulle være klar omkring 1. kvartal 2010, der vil man basere sig på OpenOffice.org 3.
Jeg går også ud fra at man så vil benytte den OOXML
understøttelse der ligger i OpenOffice.org 3.

Det betyder jo at man nu har udviklet en delvis OOXML implementering som man så allerede inden for 6-9 måneder vil udskifte igen. Det virker jo underligt, men det kan være at man har følt at man var nødt til at vise noget og derfor ikke kunne vente 6-9 måneder på at kunne annoncere OOXML understøttelse.

  • 0
  • 0
John Foldager

har du mulighed for at uddybe og konkretisere denne påstand?

Jeg udvikler typisk i programmeringssprog (server-side) som Java, LotusScript, ILERPG og lidt PHP. Der er mig bekendt ingen open source API'er til nævnte programmeringssprog som kan hjælpe mig til nemt og hurtigt at implementere OOXML (vi taler her om 'standarden'!). Derimod er der flere projekter omkring ODF til flere af sprogene, og dét/de sprog hvor der ikke er (eller hvor jeg i hvert fald ikke har fundet frem til dem) har jeg selv kunnet implementere noget rimelig hurtigt som virker til dét/de formål som jeg har haft brug for.

Jeg har ikke læst OOXML standarden og har heller aldrig forsket i forskelle mellem OOXML og ODF, så jeg skal ikke kunne sige hvilket format der har mest 'funktionalitet', og det er også på dén baggrund at jeg ikke vil kunne sige om det ene format er bedre (rent teknisk/funktionalitets-mæssigt) end det andet. Én ting er dog sikkert for mit vedkommende og det er at ODF er til at arbejde med meget hurtigt.

Under alle omstændigheder så er alle rapporter udarbejdet af store virksomheder ikke objektive nok og kigger ikke på alle aspekter: den tekniske implementation, dokumentationen, udfordringer og muligheder for både store og meget små virksomheder. De kunne også godt begynde at kigge på hvilken vej de forskellige aktører kører og om der er vilje til at komme fremad og dele. Microsoft er som jeg læser hele debatten udelukkende interesserede i at få et stempel på at OOXML skal være ét anerkendt og brugbart format og så er de ellers fuldstændig ligeglade med om vi der benytter ikke-Microsoft sprog og ikke-Microsoft platforme kan arbejde med det uden at poste en formue i opstart. OpenOffice.org har alle dage vist innovation, åbenhed og vilje - til trods for at det primært er Sun-medarbejdere der arbejder på det. IBM har med deres Lotus Symphony arbejdet videre på OpenOffice.org og har også lovet at give meget af deres implementation tilbage til OpenOffice.org, så også de viser vilje til at komme fremad. Dét mener jeg også de har vist med hele Eclipse platformen... men dét er jo en helt anden snak.

Jeg mener også at medierne er alt, alt, alt for dårlige til at skrive om standarderne og ikke-standarderne. Gennemlæsninger af et hav af artikler på diverse sites (både danske og udenlandske) beskriver fx. hvordan Microsoft Office benytter OOXML. Ja dét kan sku' da godt være... men er det standarden OOXML de benytter eller 'forgængeren'? Der er da intet at sige til at politikerne som skal tage en beslutning er forvirrede og blot lytter til dem der er størst og snakker mest...

Som tidligere skrevet så er jeg medlem af OSL for at vise min egen støtte til et åbent og 'ligefremt' format som jeg gentagne gange har lavet løsninger til/på. Dermed ikke sagt at jeg ikke vil arbejde med OOXML. Har løsninger på vej der arbejder med dokument-formater og hvor det er op til kunden selv at beslutte om de kører med ODF, OOXML eller fx. det kinesiske UOF. ODF formatet har jeg styr på men de andre formater kommer til at tage noget længere tid at få implementeret og så er spørgsmålet om dét er pengene og tiden værd for et lille software firma som mit.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej John,

Jeg udvikler typisk i programmeringssprog (server-side) som Java, LotusScript, ILERPG og lidt PHP. Der er mig bekendt ingen open source API'er til nævnte programmeringssprog som kan hjælpe mig til nemt og hurtigt at implementere OOXML (vi taler her om 'standarden'!).

Nu lavede jeg en lille, hurtig søgning og fandt følgende:

PHP:
http://openxmlapi.codeplex.com/
http://openxmldeveloper.org/articles/1515.aspx
http://openxmldeveloper.org/search.aspx?q=PHP&p=1

Java:
http://openxmldeveloper.com/archive/category/1008.aspx

(jeg har ikke ledt efter LotusScript eller ILERPG)

Jeg siger ikke, at der er [i]flere[/i] eller [i]lige så mange[/i] "OSS"-projekter til OOXML som til ODF, men det er ikke korrekt, at der ikke findes OSS OOXML værktøjer.

I øvrigt - den udtalelser jeg gerne ville have, at du konkretiserede var, at du sagde, at

[ODF] er et format som også små virksomheder kan implementere

Taler du om at implementere ODF som sådan, taler du om at implementere en delmængde af ODF eller taler du om at implementere ODF via tilgængelige API'er?

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Michael,

Du har glemt en: Abiword.

Ja - listen var ikke udtømmende men "blot" en liste over de større implementeringer, som jeg lige kunne hitte på.

Personligt synes jeg dens understøttelse af OOXML, er bedre end OOo 3.1. Seneste release indeholder denne spændende bemærkning i release notes:

Make sure the Office Open XML exporter writes out valid documents  

Har du testet udsagnet?

Nej - men det er da en god idé. Du er velkommen til at danne nogle dokumenter med AbiWord og sende dem til mig, så skal jeg teste det.

(findes AbiWord i ubuntus pakke-manager?)

  • 0
  • 0
John Foldager

Taler du om at implementere ODF som sådan, taler du om at implementere en delmængde af ODF eller taler du om at implementere ODF via tilgængelige API'er?

Ahhh.... nu er jeg med!

Jeg mener dét bør være underordnet! Uanset om man ønsker at benytte høj-niveau API'er eller ønsker at få snavs under neglene og selv parse og/eller opbygge selve den fysiske fil så bør det ikke kræve en initiel investering i tid og penge der "gør ondt" for små virksomheder.

Jeg er dog enig med dig i at man bare kan søge og så finde diverse API'er der kan løse ens behov her og nu. Men hvis man ønsker at 'standardisere' sin kode på tværs af sprog og platforme så tror jeg der er meeeeeeeget lang vej før dét sker for de sprog jeg benytter. Derfor er jeg nødt til selv at kigge på selve standarderne. Jeg ved godt at det nok er 90-95 (måske mere) af danske virksomheder der når de skal lave OOXML og/eller ODF implementationer kan nøjes med ét API, ét sprog, én platform som det ser ud idag. På dét punkt er vi tilbage til dengang hvor Microsoft Internet Explorer begyndte at lave sin egen 'standard' og som rigtig mange webløsninger idag lider under. Déngang ville virksomheder og offentlige institutioner ikke betale for at man lavede noget der benyttede standarderne og som var testet i flere browsere på flere platforme. Dét kommer de så idag til at betale endnu mere for idag da det er langt sværere at debugge sig frem til at ændre en proprietær løsning til noget der virker på flere platforme end det havde været at bruge 10-15 % mere tid dengang på at lave noget som idag blot måske skulle have et ansigts-løft i form af CSS. Nå...dét var vist lidt et sidespor... men alligevel...

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej John,

Ahhh.... nu er jeg med!

Jeg mener dét bør være underordnet! Uanset om man ønsker at benytte høj-niveau API'er eller ønsker at få snavs under neglene og selv parse og/eller opbygge selve den fysiske fil så bør det ikke kræve en initiel investering i tid og penge der "gør ondt" for små virksomheder.

Nej - og det er altså min påstand, at det heller ikke er tilfældet med OOXML. Jeg har fx selv implementeret SpreadsheetML-understøttelse i nogle biblioteker, og det er altså ikke raketvidenskab. Jeg implementerede selv XML-markup til SpreadsheetML, da der på det tidspunkt ikke var nogen OSS-biblioteker, der kunne det.

Det er naturligvis korrekt, at hvis man intet ved om OOXML, så skal man lige sætte sig ind i det - men det er jo også tilfældet, hvis vi taler om ODF. Jeg siger heller ikke, at der ikke er svært forståelige områder i OOXML - men det er der altså også i ODF.

Indlæringskurven for OOXML vil jeg vurdere kun er marginalt stejlere end for ODF (og ja, jeg har også arbejdet med ODF på format-niveau - jeg blev faktisk spurgt af Sun, om jeg ikke ville være tovholder på deres .Net ODF projekt AODL).

Jeg har dermed faktisk prøvet det du påstår ikke kan lade sig gøre - og jeg må sige, at du på baggrund af mine erfaringer tager fejl.

:o)

  • 0
  • 0
Martin Bøgelund

Det er hyklerisk, fordi det udstiller den totalt manglende evne/lyst til at gribe i egen barm og kritisere fx OOo for deres handlemåde. At OOo som default produktionsformat anvender

Jeg er stadig ikke med. Var du ikke én af dem der ønskede at diskutere ODF fremfor OOo og dens fætre? Jeg er slet ikke med på hvad det er du kritiserer, når du skiftevis kritiserer ODF og OOo, og kritiserer OOo for egenskaber ved ODF og vice versa.
Er det ikke bare fordi du er sur på Morten/OSL, og så skal alt det han taler for, rakkes ned?

Bare fordi man synes ODF er et godt format, er man vel ikke tvunget til at sætte ISO-ODF som default? Og selvom den stærke interoperabilitet mellem OOo og dens fætre er opnået gennem fælles kode, så er interoperabiliteten et faktum, og selv Jasper siger at du ikke kan konkludere noget om ODF på baggrund af interoperabiliteten - så hvorfor vil du nu blande de to ting sammen?

Din lyst til at kaste med nedladende billeder og udtryk flyver hen over hovedet på mig - jeg ved simpelthen ikke hvem du kalder hyklere, når du blander det hele sammen.

Jeg kan bare se at
- ODF er et åbent dokumentformat
- ODF er sømløst understøttet i flere kontorpakker
- Interoperabiliteten over ODF i de forskellige kontorpakker er kommet med ekspresfart
- Sømløsheden er sikret gennem kodedeling via en open source udviklingsmodel

Ting som lynhurtigt giver slutbrugeren frihed og vagmuligheder. Hvad er status lige på OOXML på disse punkter? Og er du en hykler, fordi du ikke vil tale om dét? Det synes jeg ikke, men hvad nu hvis du begyndte at måle dig selv med din egen tommestok?

Hvis du er så vild med ISO-ODF, så installer da for pokker den OOo som læser/skriver den som default.

ODF og OOo-familien går bare enormt godt i spænd, og leverer de ting som man ønskede at opnå gennem åbne dokumentformater. Hvorfor skal det være svært at tale om andres succes og glæde sig over at vi kan komme i mål på åbne dokumentformater?

  • 0
  • 0
Dennis Krøger

Jeg mener dét bør være underordnet! Uanset om man ønsker at benytte høj-niveau API'er eller ønsker at få snavs under neglene og selv parse og/eller opbygge selve den fysiske fil så bør det ikke kræve en initiel investering i tid og penge der "gør ondt" for små virksomheder.

Ikke enig. Hvis man ønsker at "få snavs under neglene", må man bruge den ekstra tid. Hvis højniveau funktioner altid skulle kunne implementeres "i hånden" hurtigt, ville vi ikke være ret langt.

  • Hele idéen med moderne former for programmering er genbrug.

Du forventer heller ikke at kunne gå på Internettet og browse AJAX sites med din eget hjemmebyggede OS inden for en måned, vel?

  • 0
  • 0
John Foldager

Jeg har dermed faktisk prøvet det du påstår ikke kan lade sig gøre - og jeg må sige, at du på baggrund af mine erfaringer tager fejl.

Dét glæder mig hvis du har ret.

Hvis nu jeg skulle lave et projekt hvor jeg havde brug for at lave en slags diff mellem 2 dokumenter og give brugeren mulighed for at merge hele eller dele af de to dokumenter sammen og samtidig sørge for overholdelse af diverse styles/formatteringer er det med dine briller så en opgave hvor man blot skal læse et par arktikler på nettet om den overordnede struktur eller skal man ned og læse hele eller store dele af specifikationen? Jeg taler ikke om at åbne dokumenterne vha. API'er og sammenligne paragraffer, men taler om at "hånd-læse" filerne og fx. kunne merge en ekstra kolonne eller række fra en tabel i det ene dokument sammen med det andet.

Jeg ved godt détte scenarie måske er lidt mere avanceret end dét de fleste løsninger omkring dokumenter kommer til at implementere, men omvendt så er det nogen gange sådan nogle løsninger som små softwarehuse får tildelt.

  • 0
  • 0
John Foldager

Dennnis,

Ikke enig. Hvis man ønsker at "få snavs under neglene", må man bruge den ekstra tid. Hvis højniveau funktioner altid skulle kunne implementeres "i hånden" hurtigt, ville vi ikke være ret langt.

Som jeg også selv skriver så er jeg meget villig til at få snavs under neglene, men jeg forstår ikke hvorfor jeg skal til at læse en 6.000-siders specifikation som ingen endnu har kunnet påvise er en 100% åben standard uden nogen former for proprietære teknologier eller områder som kan danne grobund for tvivl ifm. hvordan det skal implementeres. Og nej du har ret.... vi ville ikke være ret langt hvis vi skulle kode det hele i hånden udfra fx. OOXML speficikationen.

  • Hele idéen med moderne former for programmering er genbrug.

Du har så ganske ret igen. Det er også derfor jeg forsøger at standardisere mine egne API'er på tværs af de platforme og sprog som jeg benytter, og derfor bør det også være 'lige til at gå til'. Det er det bare ikke når specifikationerne bliver for store og som jeg også skriver ovenfor endnu ikke har overbevist mig om at den er 100% åben og ikke har uspecificerede områder i sig.

  • 0
  • 0
Jonas Finnemann Jensen

Derfor er status jo lige nu, at der (for de store leverandører) er ved at komme OOXML-understøttelse i disse programmer:

Microsoft: Microsoft Office
Apple: iWorks/TextEdit/iPhone
Corel: Word Perfect
Google: Google Docs (*)
Sun/ORACLE: OOo
IBM: Lotus Symphony
(øh?): NeoOffice

Men hvor mange af disse understøtter i dag OOXML godt nok til at det rent faktisk kan bruges til noget?
Og hvad er sandsynligheden for at det sker i fremtiden...

  • 0
  • 0
Henrik Jensen

ingen endnu har kunnet påvise er en 100% åben standard uden nogen former for proprietære

Men der er jo heller ikke nogen der har kunne påvise det modsatte.

Der er jo tilmed en række kontorpakker som er kommet et stykke af vejen med at implementere OOXML. Hvis Sun, IBM m.fl. indtil nu havde stødt på en masse proprietær teknologi i OOXML som de ikke kunne understøtte, tror du så ikke at de ville have benyttet chancen til at gøre opmærksom på dette?

Der er nogle organisationer og enkelt personer som sjældent lader en chance for at kritisere Microsoft og OOXML passere, så hvorfor skulle de have gjort det i dette tilfælde?

teknologier eller områder som kan danne grobund for tvivl ifm. hvordan det skal implementeres.

Der vil altid være steder i en nye standarder som ODF og OOMXL hvor at man finder ud af at der kan præciseres m.v. De skal modnes over en årrække.

Men "grobund for tvivl" er jo også et godt eksempel på at man ikke uden videre bare kan antage at desto kortere standard desto bedre. F.eks. indeholder OOXML standarden jo XML eksempler og masser af steder er der benyttet illustrationer for yderligere at hjælpe læseren. Det gør ODF meget lidt brug af. Nogen synes nok godt om disse eksempler / illustrationer og synes at de hjælper under implementeringen og andre synes nok at de ikke hjælper, og i så fald står det dem jo frit for at skippe meget hurtigt hen over disse eksempler og illustrationer.

For øvrigt nu nævnte du diff/merge på OOXML. Jeg ved godt at dit spørgsmål ikke var om der allerede findes et værktøj ti det men hvor meget arbejder der er i at gøre det selv. Men Altovas DiffDog
(http://www.altova.com/diffdog/ooxml-diff.html) understøtter dette. Hvor godt ved jeg ikke. Hvis det bare er deres almindelige xml diff/merge så er min erfaring at det i hvert fald ikke er et slutbruger men et udviklerværktøj.

  • 0
  • 0
Anonym

Jesper,

Det bliver faktisk utroligt spændende at se, hvordan det spænder an ... og om det rent faktisk kan lade sig gøre at lave god interop på baggrund af OOXML - og forskellige kodebaser.

Den spænding og store udgift, kan jeg godt være foruden...
[påstand]
Hvis det lykkes at opnå god/fuld interop, vil Microsoft straks proppe så mange 'ekstrafeatures' ind i deres Officepakke at den ophører med at eksistere. De vil lægge hænderne over kors og skråsikkert udbryde: "Vi kan ikke vente på de andre producenter, brugerne efterspørger dette, og vi ønsker at vores produkt skal være det bedste". Der står 'de andre' så, propfodret med tudekiks, og med en regning for at forsøge, at opnå interop.
Det er som at jage ufo'er og spøgelser...
[/påstand]

  • 0
  • 0
John Foldager

Henrik,

Men der er jo heller ikke nogen der har kunne påvise det modsatte.

Du har fuldstændig ret og netop derfor bør man da også stille sig selv dét spørgsmål om specifikationen er god nok!

Der er jo tilmed en række kontorpakker som er kommet et stykke af vejen med at implementere OOXML. Hvis Sun, IBM m.fl. indtil nu havde stødt på en masse proprietær teknologi i OOXML som de ikke kunne understøtte, tror du så ikke at de ville have benyttet chancen til at gøre opmærksom på dette?

Mit gæt er at de nævnte leverandører er blevet tvunget til at implementere så meget af specifikationen som muligt for at kunne 'sælge' (omend de er gratis) deres produkter til de lande som har standardiseret på OOXML.
Og forøvrigt så mener jeg også at de selvsamme leverandører har været ude og argumentere for de områder af specifikationen som kan rejse tvivls-spørgsmål.

Der er nogle organisationer og enkelt personer som sjældent lader en chance for at kritisere Microsoft og OOXML passere, så hvorfor skulle de have gjort det i dette tilfælde?

Tjaa... ligesom der er nogle der kritiserer den anden vej rundt og siger at open source projekter ikke spiller godt sammen, men at fx. Microsoft programmer arbejder bedre sammen. Verden er nu engang sådan skruet sammen at der findes et hav af applikationer som end ikke er i Microsoft's applikations-palette samt en række platforme som benyttes rundt omkring i virksomhederne og organisationerne. Det er disse som skal kunne tale sammen. Det ville jo heller ikke nytte noget hvis jeg som TDC kunde kun kunne ringe til andre TDC kunder, eller at jeg fordi jeg har en Nokia eller HTC eller anden type mobil kun kan ringe til tilsvarende mobiler.
Jeg forsøger ikke at kritisere Microsoft! De har gjort et kæmpe arbejde i at udarbejde en specifikation som kan en masse ting og som er givet videre til en standardiserings-organisation. Hatten af for dét! Dét jeg kritiserer er at man har lavet en ny standard som mange medier omtaler som en som kun virksomheder i Microsoft-størrelse kan drage det fulde udbytte af, og hvor man tilmed ikke kan sige at med dén og dén ændring så er specifikationen klokke klar.

Der vil altid være steder i en nye standarder som ODF og OOMXL hvor at man finder ud af at der kan præciseres m.v. De skal modnes over en årrække.

Dét har du ret i, men jeg synes der har været rigtig mange spørgsmål og undren til ting i OOXML specifikationen som har fået svar og ting der er blevet ændret, men ligemeget nytter det... vi står stadig med en specifikation som ingen ved hvordan skal fortolkes ud i hjørnerne. Dét er da et problem at den er blevet godtkendt efter alt dette.

Men "grobund for tvivl" er jo også et godt eksempel på at man ikke uden videre bare kan antage at desto kortere standard desto bedre.

Jeg taler heller ikke om størrelsen på specifikationen. Bare den er til at forstå og 'let' at komme igang med og uden områder hvor man må stille spørgsmål. Det kan godt være at hvis man kunne få specifikationen uden eksemplerne og illustrationerne at den så var noget mere appetitlig at gå igang med at læse og hvis man så kunne vise eksempler og illustrationer dé steder hvor man var i tvivl så kunne det måske hjælpe.

Det optimale scenarie ville være hvis ODF, UOF og OOXML kunne samles i ét format. Så kan det godt være det ville være en lidt større specifikation end ODF er idag, men så har vi én specifikation at læse. Jeg skal dog lige understrege at hvis dét skulle kunne lade sig gøre så skulle dén specifikation selvfølgelig ikke have punkter som kunne danne tvivl.

For øvrigt nu nævnte du diff/merge på OOXML. Jeg ved godt at dit spørgsmål ikke var om der allerede findes et værktøj ti det men hvor meget arbejder der er i at gøre det selv. Men Altovas DiffDog
(http://www.altova.com/diffdog/ooxml...) understøtter dette. Hvor godt ved jeg ikke. Hvis det bare er deres almindelige xml diff/merge så er min erfaring at det i hvert fald ikke er et slutbruger men et udviklerværktøj.

Tak for info. Nu var mit eksempel nu mere myntet på en applikation som slutbrugeren skulle benytte til let og overskueligt at flette 2 versioner af samme dokument sammen. Ikke et spørgsmål om at finde API'er eller tools som idag kan hjælpe med dette. Altova's produkt er mig bekendt et Microsoft Windows produkt og ville som sådan ikke kunne benyttes hos et udsnit af mine kunder som enten kører Linux eller Mac OS X på klienterne og heller ikke hvis vi implementerede en web-baseret løsning som fx. skal køre fra en IBM i (AS/400).

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Jonas,

Men hvor mange af disse understøtter i dag OOXML godt nok til at det rent faktisk kan bruges til noget?

Microsoft: Microsoft Office
Apple: iWorks/TextEdit/iPhone
Corel: Word Perfect
Google: Google Docs (*)
Sun/ORACLE: OOo
IBM: Lotus Symphony
(øh?): NeoOffice

Umiddelbart vil jeg vurdere, at følgende er "produktionsmodne:

Microsoft Office
iWorks/TextEdit/iPhone (sidstnævnte dog kun visning)
Google Docs
NeoOffice

Jeg har ikke testet Corel Word Perfect for nyligt - men da den lige blev lanceret, var OOXML-understøttelsen ikke noget at skrive hjem om.

Og hvad er sandsynligheden for at det sker i fremtiden...

OOXML-understøttelse er udgangspunktet for at være relevant på markedet (ligesom Sun siger det). Derfor er sandsynligheden 100% for, at alle større kontorpakker vil understøtte OOXML - ganske som de nu understøtter .DOC.

Må jeg tilsvarende spørge: hvor mange kontorpakker, der ikke er baserede på OOo-kildekode, kan "rent faktisk kan bruges til noget" til ODF-arbejde?

(det er ikke et trick-spørgsmål)

  • 0
  • 0
Henrik Jensen

Du har fuldstændig ret og netop derfor bør man da også stille sig selv dét spørgsmål om specifikationen er god nok!

Det forstår jeg ikke. Hvis der ikke er nogen der har kunne påvise at OOXML ikke er 100% åben så man man stille sig spørgsmål ved om specifikation er god nok? Der er jo heller ikke nogen der har kunne påvise at ODF ikke er 100% åben, betyder det så også at man kan stille spørgsmålstegn ved den.

Jeg vil da mene at det er lige omvendt.

Og forøvrigt så mener jeg også at de selvsamme leverandører har været ude og argumentere for de områder af specifikationen som kan rejse tvivls-spørgsmål.

Jeg synes godt jeg har set meget lidt konkret, altså hvor man går ind og siger på side 2147 står der XYZ, og der mener vi at..... og rigtig meget ukonkret hvor man bare påstår at standarden ikke er åben, at den indeholder funktionalitet som kun kan implementeres på windows osv. og de konkrete eksempler har man så stående på en hemmelig liste som man ikke vil udlevere til nogen som helst.

Men selvfølgelig kan man altid finde nogle småting og det gælder jo både ODF og OOXML og for den sags skyld alle andre standarder. Det er jo også derfor at man nu er klar med nogle rettelser til OOXML (COR1 til IS29500) ligesom der er udarbejdet errata dokumenter til ODF standarden. Det er blot en naturlig del af standardisering.

vi står stadig med en specifikation som ingen ved hvordan skal fortolkes ud i hjørnerne

Hvem er vi, hvor er de konkrete eksempler, og har man indberettet de konkrete eksempler til de folk der vedligeholder OOXML?

Jeg er desuden helt med på at der er rigtig rigtig mange som aldrig har læst standarden eller som kun brugt 1-2 timer på at skimme den igennem og som ikke kan fortolke den ud i alle hjørner. Det har jeg heller aldrig følt var et realistisk scenarie.

Det optimale scenarie ville være hvis ODF, UOF og OOXML kunne samles i ét format.

Enig det optimale scenarie ligger dog bare rigtig rigtig langt ude i fremtiden og man skal igennem en proces for at nå dertil. Man kan ikke forvente at lige pludselig en dag 15 år ude i fremtiden så er det optimale scenarie opnået uden at vi har været igennem en proces med en masse mindre optimale scenarier undervejs. Et første skridt på vejen kunne være at få ODF vedligehold overgivet til ISO så den gruppe der er nedsat til kigge på harmoniseringen mellem ODF og OOXML for alvor kan få noget at arbejde med og en større grad af indflydelse på ODF.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Christian,

Den er blevet kørt ud på et sidespor sammen med en masse anden banebrydende MS teknologi, så som virus!

Hmmm ... jeg installerede da Lotus Symphony i går på min MacBook, og her var det da også via "Download .DMG, 2xClick to install".

Det virker ganske upåklageligt.

(altså efter jeg havde kæmpet mig igennem det kafkaske brugerinterface på IBMs downloadside)

Iflg PHK er MacOS da netop "one of the good guys" ifht sikkerhed.

http://www.version2.dk/artikel/11956-folk-der-ikke-ved-bedre

:o)

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Martin,

Er det ikke bare fordi du er sur på Morten/OSL, og så skal alt det han taler for, rakkes ned?

Nej - jeg er bestemt ikke sur på OSL - men jeg synes da, at de opfører sig lidt mystisk i denne sag.

Jeg kan bare se at
- ODF er et åbent dokumentformat
- ODF er sømløst understøttet i flere kontorpakker
- Interoperabiliteten over ODF i de forskellige kontorpakker er kommet med ekspresfart
- Sømløsheden er sikret gennem kodedeling via en open source udviklingsmodel

Jeps - og ovenstående er jeg sådan generelt ganske enig i. Problemet kommer blot, når man forsøger at argumentere for, at det er "ODFs skyld", at ovenstående er korrekt. Det er netop det OSL bruger som (fejlagtig) argument for at vælge en ODF-only løsning.

Mit argument er, at - bortset fra første punkt - du kan udskifte "ODF" med "DOC" og få samme punkter som ovenfor.

(Når jeg er lidt vævende med at acceptere alle punkterne ovenfor som sande, så skyldes det, at jeg ikke synes, at "god interop" via ODF er kommet med ekspresfart. ODF blev godkendt af OASIS i 2005, og i dag næsten 4 år senere er der kun (tilstrækkelig god interop via ODF, hvis man bruger én leverandørs ODF-motor. Jeg synes ikke, at man generelt på tvæsr af markedet kan sige, at den gode interop med ODF er kommet med ekspresfart - for den er ikke-eksisterende)

Ting som lynhurtigt giver slutbrugeren frihed og vagmuligheder. Hvad er status lige på OOXML på disse punkter? Og er du en hykler, fordi du ikke vil tale om dét? Det synes jeg ikke, men hvad nu hvis du begyndte at måle dig selv med din egen tommestok?

Der er bestemt intet hykleri fra min side her, for jeg er helt enig med Konkurrencestyrelsen i, at OOXML ikke er godt nok understøttet i markedet i dag til at blive valgt som eneste dokumentformat. Det vil jeg meget gerne tale om - og jeg har flere gange fastslået, at jeg er helt enig med Konkurrencestyrelsen i deres konklusion omkring præcist OOXML.

Så nej, jeg har intet problem med at påpege fejl og mangler ved OOXML - når de er berettigede.

Og så lidt mere hykleri: Prøv at tænk over, hvor mange gange i de sidste dage, der er debattører, der har spredt FUD omkring at der måske etellerandetsted muligvis sandsynligvis er proprietære afhængigheder i OOXML. Beskyldningerne bliver bragt til torvs uden nogen form for dokumentation andet end "man kan jo ikke afvise det".

Lad mig hermed benytte lejligheden til at afvise påstanden:

"Der findes ingen proprietære afhængigheder i OOXML"

Dette gælder både ECMA-376 og IS29500.

... men ... de findes pudsigt nok i ODF. Der er funktionalitet i ODF, som ikke kan implementeres uden anvendelse af proprietær, ikke-standardiseret teknologi. Det er ikke nogen hemmelighed, at de findes - men det er åbenbart ikke noget problem ... hvis altså ikke lige vi taler om OOXML.

Hyklerisk (eller blot ignorance/uvidenhed?)

:o)

  • 0
  • 0
Erik Cederstrand

@Jesper

Der er funktionalitet i ODF, som ikke kan implementeres uden anvendelse af proprietær, ikke-standardiseret teknologi.

Æv, dit indlæg startede lige så godt, og så smider du den bombe. Du har jo en stor indsigt i de to formater, så jeg siger ikke du tager fejl, men det virker ikke særlig seriøst at anklage andre for udokumenterede beskyldninger, for selv at gøre det i samme åndedrag.

Vil du ikke lige, for din egen skyld, uddybe og dokumentere din påstand?

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Erik,

Vil du ikke lige, for din egen skyld, uddybe og dokumentere din påstand?

Er det ikke pudsigt? I samme øjeblik jeg kommer med udokumenterede påstande om ODF, så skal jeg straks redegøre for dem ... men udokumenterede påstande om OOXML får bare lov til at flyve rundt i luften.

Anyways - i ODF 1.2 CD03 (seneste semi-officielle kladde fra 30. juli d.å.) sektion 9.4.6.1 er beskrevet elementet "<draw:applet>". Dette element giver en klar fortrinsret for Suns proprietære Java-teknologi og tillader kun andre teknologier at bruge det generiske "<draw:object-ole>"-element.

I HTML-sammenhænge har man for længst indset, at det ikke er acceptabelt i en standard at have denne forskelsbehandling, så <applet>-elementet er nu deprecated til fordel for <object>-elementet, der stiller alle leverandører lige.

http://www.w3.org/TR/REC-html40/struct/objects.html#edef-APPLET

Men i CD03 for ODF 1.2 har man - uagtet at ODF TC er blevet gjort opmærksom på det i marts 2009 - ikke ændret det.

http://lists.oasis-open.org/archives/office-comment/200903/msg00141.html

Man kan naturligvis sige, at det jo ikke betyder så meget - man kan jo bare bruge den generiske måde eller lave en applet, men jeg kan godt huske ramaskriget i 2007 over tilsvarende constructs i OOXML, der gav Windows en slags preference ifht andre teknologier (clipboard-format, target-eksport format til HTML etc). Men når det drejer sig om ODF, så er det åbenbart ligememeget. De problematiske constructs er i øvrigt blevet ændret i forbindelse med DIS29500-processen)

Og igen sniger hykleriet sig ind. Jeg ville da forvente, at hvis problemet var så stort, som det blev fremstillet i 2007, så ville der da være nogen, der havde kigget i CD03, opdaget, at det ikke var med og sendt en mail til ODF TC eller evt DS (som jo har det danske ISO/ODF-ansvar) om at rette op på disse ting.

... men der har været en øredøvende stilhed.

  • 0
  • 0
Martin Bøgelund

Anyways - i ODF 1.2 CD03 (seneste semi-officielle kladde fra 30. juli d.å.) sektion 9.4.6.1 er beskrevet elementet "<draw:applet>". Dette element giver en klar fortrinsret for Suns proprietære Java-teknologi og tillader kun andre teknologier at bruge det generiske "<draw:object-ole>"-element.

Så vidt jeg kan se var elementet "<draw:applet>" også til stede i ODF 1.1 (9.3.4), uden der blev råbt op. Hvorfor er det først et problem i 1.2 CD03 så?

Man kan jo også sige at Java er multiplatform, hvorimod Windows er temmelig single-platform...

At en åben standard indeholder referencer til et multiplatform-element, ser jeg som et væsentligt mindre problem, end hvis en såkaldt åben standard indeholder referencer til én enkelt platforms konstruktioner.

Og nu vi er ved åbenhed: Jeg kan bruge Java på mit system, uden at skulle betale for det nogensinde, Sun har nemlig open sourcet koden.

Hvis jeg benytter Windows på mit system uden at betale for det, kriminaliserer jeg mig selv.

Det underlige er, at du har forbigået disse ting med øredøvende stilhed.

Er det nu vi skal måle dig med din egen tommestok?

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Martin,

Så vidt jeg kan se var elementet "<draw:applet>" også til stede i ODF 1.1 (9.3.4), uden der blev råbt op. Hvorfor er det først et problem i 1.2 CD03 så?

Jeg tror faktisk, at det var med allerede i ODF 1.0, men det viser jo med al tydelighed, at ODF aldrig er blevet rigtigt gennemlæst i detaljer - før nu.

Og naturligvis var det også et problem i ODF 1.1/ODF 1.1. Jeg arbejdede ikke med dokumentformater, da ODF 1.1 blev godkendt, men det er meget naturligt, at nu da ODF 1.2 er ved at være færdigbagt, at man/jeg kigger på, om der er nogle ting, der skal laves om. Jeg regner også med, at disse ting lander på bordet i DS, når (hvis) ODF 1.2 bliver sendt til ISO.

Man kan jo også sige at Java er multiplatform, hvorimod Windows er temmelig single-platform...

At en åben standard indeholder referencer til et multiplatform-element, ser jeg som et væsentligt mindre problem, end hvis en såkaldt åben standard indeholder referencer til én enkelt platforms konstruktioner.

Du misforstår (men måske har jeg ikke været grundig nok til at forklare det). Der har aldrig i OOXML været afhængigheder til Windows-specifikke instruktioner, der krævede Windows for at kunne bruges. Der har derimod været nogle constructs, hvor fx clipboard-format kunne specificeres som "Windows", "Mac" og "Other". Kritikken (som jo i øvrigt var ganske valid) gik på, at det gjorde det nemmere at implementere OOXML på Windows-platformen end på andre platforme. Dette kritikpunkt er også gældende for ODF, for Suns Java-teknologi har en klar fortrinsret i ODF.

Og nu vi er ved åbenhed: Jeg kan bruge Java på mit system, uden at skulle betale for det nogensinde, Sun har nemlig open sourcet koden.

Hvis jeg benytter Windows på mit system uden at betale for det, kriminaliserer jeg mig selv.

Joeh, men det er jo ikke det, som kritikken har gået på. Kritikken har jo været, at OOXML var "sovset ind i proprietært snask" (eller sådan noget). Forskellen på OOXML og ODF er her, at det faktisk ikke er tilfældet for OOXML - men meget sandt for ODF.

Java er en proprietær teknologi ejet og kontrolleret af Sun. Det ændres ikke af, at Sun har lagt dele (eller det hele?) ud til download.

Det underlige er, at du har forbigået disse ting med øredøvende stilhed.

... jeg har haft alt, alt, alt for travlt med at affærdige urigtige påstande om OOXML :o)

  • 0
  • 0
Erik Cederstrand

Er det ikke pudsigt? I samme øjeblik jeg kommer med udokumenterede påstande om ODF, så skal jeg straks redegøre for dem ... men udokumenterede påstande om OOXML får bare lov til at flyve rundt i luften.

Jeg benægter ikke fanboyismen her i debatten, og min mening var ikke at sige "hvad med dig selv". Det var en venlig henstillen til, at du ikke forfaldt til den samme standard. Du er en af de få her, som ved hvad du snakker om, så jeg glæder mig i samme åndedrag over din uddybning.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Hej Jesper,

Altså skal vi have noget på det rene før der kan diskuteres:

  • Du er "lakaj" for Jasper (du har jo siddet og været med til at godkende OOXML), altså er du partisk, og vil forsvare dit arbejde med næb og klør. Dit tilhørsforhold gør at han helt og holdent er subjektiv. Du har jo selv fortalt at du valgte at arbejde med OOXML, men sagde nej tak til ODF.

  • Java er IKKE en proprietær standard, men en åben standard med mange implementationer (Apple, IBM, BEA nu Oracle, Apahce osv.). Java er tilmed open source.

Dette med pludseligt at begynde at svine Java til med usande og ikke underbyggede påstande, klinger lidt hult, når du i samtlige tråde omkring OOXML bakker M$ og Jasper op.

Altså du taler om hyklere og ikke underbyggede påstande, og så kommer du med en om Java som i den grad sår tvivl omkring dit arbejde og din objektivitet.

Set rent pragmatisk, hvad skal vi med OOXML? ODF virker fint og der er masser af interop med andre pakker. Det kan man ikke sige om OOXML. Du siger det kommer der måske i fremtiden - hvad er det vi skal bruge det til? At alle ODF understøttende pakker bruger samme motor, viser jo bare hvorfor Open Source modellen i sidste ende er stærkere en M$ proprietære model. Genbrug er da fantastisk, så kan vi bruge pengene på at løse problemer - i stedet for at genopfinde den dybe tallerken.

Hvad er det OOXML indeholder som vi bare skal have og ikke kan få fra ODF? Altså i stedet for at bruge din tid på at slås for OOXML - ville det så ikke være bedre at du brugte den på at forbedre alle de mange fejl du ser i ODF?

Altså det er jo VHS/Betamax, 110/230 Volt, PAL/NTSC, 50/60 Hz, BluRay/HD-DVD diskussionen igen. Ting som igen og igen volder problemer og som er åndsvage - og kun tjener leverandørers formål og ikke forbrugeren.

Se iøvrigt http://tools.oasis-open.org/issues/browse/OFFICE-2044 angående <drav:applet>

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Nicolaj,

  • Du er "lakaj" for Jasper (du har jo siddet og været med til at godkende OOXML), altså er du partisk, og vil forsvare dit arbejde med næb og klør.

Det er ikke korrekt. Jeg mener naturligvis, at de beslutninger jeg har været med til at tage er de rigtige - hvofor skulle jeg ellers tage dem? Derfor kan jeg også relativt simpelt redegøre for, hvorfor jeg har gjort det ene eller det andet.

Dit tilhørsforhold gør at han helt og holdent er subjektiv. Du har jo selv fortalt at du valgte at arbejde med OOXML, men sagde nej tak til ODF.

Igen - det er ikke korrekt. Jeg har sagt, at jeg primært arbejder med OOXML, da jeg og CIBER her vurderede, at vi kunne påvirke arbejdet mest positivt her - men jeg bidrager til ODF-samarbejdet også. Eksempelvis arbejder jeg i disse dage på at implementere fuld support for alle celle-type-værdier i ODF i Suns ODFToolkit/AODL-projekt. Jeg bidrager også til udviklingen af ODF via både Dansk Standard og (mere direkte) via ODF TCs mailliste, hvor jeg så sent som i sidste uge indsendte endnu et forslag til forbedring af ODF.

Det er naturligvis nemt og taknemmeligt for dig og andre at svine mig til som "OOXML-elsker" hhv. "ODF-hader", men sandheden er en anden.

  • Java er IKKE en proprietær standard, men en åben standard med mange implementationer (Apple, IBM, BEA nu Oracle, Apahce osv.). Java er tilmed open source.

At en teknologi er "open source" gør den ikke nødvendigvis til "ikke-proprietær". Microsoft har fx gjort ASP.Net MVC "open source", men det er stadig Microsoft, der kontrollerer programmet.

Tilsvarende har Sun gjort "selve Java" open source, men Sun sidder 112% på det værktøj, der giver mulighed for at kalde sig "java" (Java TCK/JCK). Derfor er "Java" stadig en proprietær teknologi (da den er ejet af Sun), for de bestemmer suværent over det værktøj, der testes imod.

Det er sandsynligvis netop denne konstruktion, der har fået Sun til at trække følehornene til sig i forbindelse med de gange, hvor de forsøgt at overgive Java til en standardiseringsorganisation. De ville simpelthen miste kontrollen over Java.

http://www.sun.com/software/opensource/java/faq.jsp#k1

Så ja, Java er stadig en proprietær teknologi - selvom den er licenseret via GPL2.

når du i samtlige tråde omkring OOXML bakker M$ og Jasper op.

Jeg bakker faktisk uhyre sjældent Jasper op - han er en stor dreng og kan klare sig selv. Jeg bakker heller ikke OOXML op ukritisk. Jeg har fx i samtaler med Christian Nobel udtrykt min klare forundring/irritation over kompleksiteten af anvendelser af datoer i regneark, styles i markup etc. Jeg har endda blogget om netop dette på min engelske blog.

http://idippedut.dk/post/2009/01/29/The-complexity-of-SpreadsheetML-oh-t...

At alle ODF understøttende pakker bruger samme motor, viser jo bare hvorfor Open Source modellen i sidste ende er stærkere en M$ proprietære model. Genbrug er da fantastisk, så kan vi bruge pengene på at løse problemer - i stedet for at genopfinde den dybe tallerken.

Jeg er rørende enig - det har blot ikke noget med ODF at gøre.

Hvad er det OOXML indeholder som vi bare skal have og ikke kan få fra ODF?

Interoperabilitet med den kontorpakke, der er installeret på anslået 80-90% af alle PC'ere i Danmark.

Altså i stedet for at bruge din tid på at slås for OOXML - ville det så ikke være bedre at du brugte den på at forbedre alle de mange fejl du ser i ODF?

Som sagt ovenfor, så bidrager jeg til ODF, hvor jeg har mulighed for det. Der er fx under en håndfuld udviklere tilknyttet AODL-projektet, der er eneste open source .Net-værktøj til dannelse af ODF-filer og jeg er den ene af dem. Jeg har allerede sendt første rettelse (tilføjelse af funktionalitet) ind - og flere er på vej.

Men prøv fx at se i seneste ODF 1.2 draft i afsnittet om den nye dokumenttype "database document". Kan du af ODF 1.2 alene give en redegørelse for, hvad denne dokumenttype skal bruges til, hvilke use-cases den dækker og hvad man skal gøre? Jeg har umådeligt svært ved at gennemskue dette, for afsnittet er reelt kun en listning af XML-elementer og attributter. Der er stadig masser at kaste sig over - men som med alle andre, er min tid knap.

Anyway - OOXML har nogle egenskaber, som imo er uhyre vigtige - og det er ikke realistisk, at ODF (nogensinde) får disse inkluderet. Eksempelvis fremlagde Microsoft 15 (eller var det 12?) forslag til tilføjelser til ODF, som ville gøre det nemmere at få interop med Microsoft Office - men ingen af forslagene blev taget med i ODF 1.2 . Det synes jeg ikke borger for en kort tidsmæssig ramme for at få disse ting inkluderet i ODF.

ang: http://tools.oasis-open.org/issues/browse/OFFICE-2044 :

Det er super fedt - så kan jeg slette den mail jeg har siddet og brygget på til ODF TC om netop at tage ved lære af HTML og fjerne <applet>-elementet.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Hej Jesper,

Nu er jeg egentlig sur på OOXML af de samme årsager som jeg egentlig er sur på M$ og deres evindelige "vi har vore egen standard: JScript, OOXML osv. osv."

Og du har nok ret i mange af dine pointer på det operationelle niveau. For mig er det bare ikke godt nok, for det viser sig altid i praksis at der er M$ som ikke er interoperatibelt med noget som helst andet (prøv office på Mac - det er da en fadæse).

Når du nu nævner HTML, så er der jo HTML 4, HTML 5, XHTML og så M$ HTML.

At du stadig mener Java ikke er en åben standard som hvem som helst kan lave en implementation af, da specifikationen er helt tilgængelig er stadig en fejl. Der er indtil flere implementationer som fint kører Java, uden at have benyttet TCK/JCK.

Du kan ikke bedømme standardens åbenhed ud fra om et værktøj til at bedømme kompatibiteten af ens implementation er gratis.
Er der et ISO OOXML kompatibilitetsværktøj, til at teste at den implementation man nu har lavet virker 100%? Og er den gratis og åben?

Jeg har været medlem af JCP EC (Java Community Process Executive Commitee), der hvor Java standardiseringen foregår, så jeg ved at Java er en åben standard, du kan så have dine meninger - dog er de forkerte.

At Sun (nu Oracle) har lavet et standardisering board - og at det ikke er under W3C, OASIS, ISO eller lignende, gør ikke den store forskel.

Hvis du staidg er i tvivl så se venligst http://www.jcp.org/en/introduction/overview

Altså tag f.eks. W3C, her koster det penge (og rigtigt mange af dem) bare for at blive medlem - så hvis man gerne vil være med til at præge HTML, XML standarderne eller lignende må man op med cash, modsat JCP.

Er det så åbent? I mine øjne ja, men kun for dem med mange penge, som virkeligt er interesserede - ligesom for implementationen af "Java".

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Nikolaj,

Når du nu nævner HTML, så er der jo HTML 4, HTML 5, XHTML og så M$ HTML

Nu skal man passe på med at nævne "HTML" i forbindelse med standardisering, for HTML (og JavaScript) er et godt eksempel på, hvad der sker, når standardiseringen går for langsomt :o)

At du stadig mener Java ikke er en åben standard som hvem som helst kan lave en implementation af, da specifikationen er helt tilgængelig er stadig en fejl.

Muligvis - men jeg har ikke sagt ovenstående.

Du kan ikke bedømme standardens åbenhed ud fra om et værktøj til at bedømme kompatibiteten af ens implementation er gratis.
Er der et ISO OOXML kompatibilitetsværktøj, til at teste at den implementation man nu har lavet virker 100%? Og er den gratis og åben?

Nej, sådan et værktøj eksisterer ikke. Men prøv at forestille dig, at Microsoft "ejede" og kontrollerede det eneste officielle værktøj til test af "OOXML-kompatibilitet" og at man ikke måtte skrive "supports OOXML" eller "OOXML compatible" uden på pakken uden succesfuld test.

Det er jo den verden vi har med Java.

Derudover er der nogle andre detaljer i forbindelse med udviklingen af Java selv. Man kan bidrage til "Java", hvis man har lyst (og har fået lov), men betingelsen er, at copyright på al arbejdet gives til Sun (det er det samme med OOo). Så uanset hvordan du vender og drejer det, så er "Java" et proprietært produkt/teknologi, for Sun er indehaver af IPR til 100% af produktet.

Måske er det bedste navn for dette "POSS" - Proprietary Open Source Software".

:o)

  • 0
  • 0
Nikolaj Brinch Jørgensen

Jesper,

Det er rigtigt setup omkring Java udviklingen på IPR siden ikke er optimal. Men det har da intet med åbenhed at gøre (hvilket er det vi diskutere).

Du har rodet dig ud i alle mulige søforklaringer om det ene og det andet, fordi du, som jeg ser det er kommet med postulater en teknologi der er usande, og som kan forvirre folk (ligesom den debat der er om OOXML, ODF).

Først Open Source modellen. Det er altså sådan at med Java og Open Source modellen, så har alle som bruger Java en garanti for at der altid eksisterer en platform at afvikle den udviklede kode på, også selvom man skulle blive uvenner med Sun/Oracle, Sun/Oracle skulle gå konkurs eller lignende, i sidste ende kan man selv blive leverandør.

Nej nu er Java jo registreret varemærker. Men både Java Language Specification og Java Virtual Machine Specification er åbne og tilgængelige, og opfylder ifølge hvad jeg kan læse mig til definitionen for åbne standarder, også den danske.

Der er da masser af POSS og COSS (Commercial Open Source Software), det gør ikke argumenterne for at bruge dem frem for PCSS/CCSS mindre. Det offentlige Danmark er ved at vågne, og ligeså indtil flere virksomheder.

Så jeg kan se at du ikke kan argumentere dig ud af din knibe (det er klart du tager fejl), så derfor skal vi måske bare begrave stridsøksen, og lade det rigtige stå tilbage, nemlig at Java er en åben standard, hvor enhver kan deltage i standardiseringsarbejdet og lave en implementation af både Java Language og Java Virtual Machine (hvis ikke det var så åbent, hvordan tror du så Scala, JRuby, Groovy, Jaskell m.fl. var kommet til????).

Nikolaj

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Nikolaj,

Du har rodet dig ud i alle mulige søforklaringer om det ene og det andet, fordi du, som jeg ser det er kommet med postulater en teknologi der er usande,

Jeg har ikke på noget tidspunkt sagt noget usandt om Java. Jeg har sagt, at Java er en proprietær teknologi samt at Sun strengt kontrollerer, hvad der må kaldes "Java". Det er fuldstædingt evident, at dette er sandt. Jeg har fx derimod ikke sagt, at Java ikke var OSS.

Der er da masser af POSS og COSS (Commercial Open Source Software), det gør ikke argumenterne for at bruge dem frem for PCSS/CCSS mindre.

Nej - og jeg har heller ikke sagt det modsatte.

Så jeg kan se at du ikke kan argumentere dig ud af din knibe (det er klart du tager fejl), så derfor skal vi måske bare begrave stridsøksen, og lade det rigtige stå tilbage, nemlig at Java er en åben standard, hvor enhver kan deltage i standardiseringsarbejdet

Det springende punkt er jo ikke, om "alle kan deltage". Det springende punkt er, hvem der bestemmer. Jeg er klar over, at du er stoppet med at lytte til mig, men du kan sådan set også høre, hvad Sun selv har sagt. Deres bevæggrunde for at droppe den "rigtige" standardisering af Java var jo netop, at Sun skulle afgive kontrollen med Java. Deres bekymring var konkret, at man (i deres øjne) risikerede en fragmentering af markedet og at "write once, run everywhere" ikke længere ville gælde. Derfor trak de sig og overlod ikke kontrollen til fx ECMA.

At noget er åbent tilgængeligt er IKKE det samme som, at det en "åben standard" eller "ikke-proprietært". Før Adobe overgav PDF-formaterne (PDF og PDF/A) til ISO, var specifikationerne også alment tilgængelige og PDF er nok det mest udbredte dokumentformat, der findes, på tværs af platforme og applikationer.

Men det ændrer ikke ved, at PDF (før ISO/IEC 32000) var et proprietært format ejet og kontrolleret af Adobe.

hvordan tror du så Scala, JRuby, Groovy, Jaskell m.fl. var kommet til????).

Øeh - og jeg troede egentlig, at du var helt skarp på, hvad vi diskuterede. JRuby og Jaskell er slet ikke relevante for vores snak, da de ikke er implementeringer af Java men implementeringeer [i]i[/i] Java.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Nikolaj,

Man skal helst selv opdage, når man har taget fejl.

Det springende punkt er jo ikke, om "alle kan deltage". Det springende punkt er, hvem der bestemmer.

Jeg har læst lidt op på lektien, og jeg kan af fx http://www.jcp.org/en/participation/committee se, at det rent faktisk er lykkedes Sun at lave et forum med bred industrisammensætning til vedligeholdelse og udvikling af Java. Eneste "forhåndspræference" for Sun er iflg oversigten, at Sun altid vil have et permant, stemmeberettiget medlem af disse Executive committees. Det lyder ikke som noget stort problem.

:o)

  • 0
  • 0
Nikolaj Brinch Jørgensen

Du påstår stadig at Java er en proprietær teknologi. Hvori er teknologien proprietær? At man oversætter et program til et midlertidigt format og kører det på en virtuel maskine? Øhh det er vist ikke proprietært.
Hvad angår JLS og JVMS er de da åbne i den forstand der forstås ved åbne (Wikipedia og ifølge dansk lov).

Java er trademark, og ja hvis man vil bære dette på en JDK/JRE implementation skal man til lommerne.

Du påstulere stadigt at Java er proprietær teknologi, hvorledes underbygger du din påstand. Ved at sige det er evident at det er sandt. Du er ikke rigtigt kommet med dit bevis. Du har prøvet med hensyn til sløring via diverse henvisninger til TCK/JCK licensen, men det var ikke muligt.

http://en.wikipedia.org/wiki/Proprietary_software

JRuby m.fl. er yderst relevante, for uden den åbenhed der er i Java platformen (JVMS) var det ikke muligt at lave disse.
De er iøvrigt ikke lavet "i" Java, men "på" Java, men det er en anden diskussion :-)

Tror du iøvrigt selv at Microsoft vil lade ISO OOXML leve sit helt eget liv hos ISO, uden M$ indflydelse? Hvis ikke ISO makker ret, bliver der jo bare lavet OOXML2 et andet sted, eller Microsoft lukker igen, sådan er det når de har monopol, du og dine støtter det, og der ikke bliver lavet seriøse indgreb andetssteds fra.

Så lige for at bruge dine argumentationsformer.

"OOXML er en proprietær teknologi. Det er fuldstændigt evident, at dette er sandt."

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Nikolaj,

Jeg sagde jo faktisk i mit forrige indlæg, at jeg havde taget fejl mht Suns kontrol over Java.

Anyway, du nævner en række teknologier og especifikationer:

Java Language Specification : IRP indehaves af Sun
The Java Virtual Machine Specification : IPR indehaves af Sun
OpenJDK: IPR indehaves af Sun

Derudover hentede jeg en tilfældig BSP-port, og IPR indehaves også her af Sun.

Det er vigtigt at understrege, at således behøver det ikke at være. Deltagelse i andre store OSS-projekter indebærer ikke overdragelse af IPR til én virksomhed. For Eclipse's vedkommende skal dit bidrag blot licenseres via EPL og der er lignende konstruktioner for Apache, Mozilla etc.

For mig er IPR en ganske vigtig størrelse, og mit arbejde i ISO har gjort det klart for mig, hvor essentielt det er for arbejdet i OASIS med ODF eller ISO med OOXML. Fx kan du ikke deltage i debatterne via ODF comment mail list uden at overføre IPR på din kommentar til OASIS.

En del af "rigtig" standardisering er netop overførsel af IPR til en standardiseringsorganisation. Det er sket med ODF, OOXML og PDF, hvor IRP er blevet overdaget/delt med hhv. OASIS, OOXML og AIIM. I sidste ende er IPR delt med ISO ved godkendelsen.

Din henvisning til Wikipedia fortæller, at proprietært betyder, at ejer af IPR kan bestemme en brugers brug af softwaren (som et eksempel). Ud fra den definition er Java (tm) ikke proprietært software, og derfor skal jeg måske hitte på et andet ord for det. Jeg kan dog se på diskussionerne af den, at der er kritik af, at den måde begrebet defineres på. Jeg har aldrig påstået, at Java ikke skulle være OSS og jeg har aldrig påstået, at Java ikke skulle kunne implementeres på de platforme man ville ønske.

Der er for mig ingen tvivl om, at Java er et proprietært produkt. IPR indehaves nemlig af Sun for al nødvendig information. Sun ejer IPR for "selve Java", de bestemmer mulighederne for at bruge Java-logoet og hvis man vil implementere sin egen Java-engine, så indehaves IPR for specifikationen til at gøre dette også af Sun.

(ovenstående er ikke i modstrid med, at "Java" som sådan er OSS og at du kan bruge det stort set som du vil)

Du nævner selv OOXML som et lignende eksempel, men forskellen er her, at IPR til OOXML ikke længere indehaves af Microsoft - det indehaves af ISO. At nogen skulle kunne lave en fork af en specifikation er jo en risiko, som man må løbe - uanset om specifikationen hedder ODF, PDF, JPEG, PNG, MPEG4, C++ ... eller OOXML.

(jeg er i øvrigt helt enig med dig i, at arbejdet med at sikre, at Microsoft overholder ISO OOXML ikke stopper - blot fordi OOXML er blevet godkendt i ISO)

[b]Én ting som jeg dog har lært at vores samtale er dog, at Sun ikke har nær så meget kontrol over udviklingen af Java, som jeg troede. Jeg synes at det er et imponerende setup man har lavet med JCP/EC (som du selv nævnte tidligere) og processerne omkring det. Her har jeg åbenlyst taget fejl, og det beklager jeg naturligvis. Jeg er jo ikke politiker, så jeg kan ikke "trække noget tilbage", men jeg ville ikke have formuleret mig som jeg gjorde, hvis jeg havde den information jeg har nu.[/b]

  • 0
  • 0
Nikolaj Brinch Jørgensen

Det var bedre :-)
Ja Sun har tidligere være meget lukkede omkring Java, noget som alle deltager i JCP (både EC og andre), har været enormt utilfredse med, og har truet Sun (som jo er stor men alligevel lille når det er HP, IBM, Oracle, Intel, Nokia osv. der brokker sig).
Ligesom og "forbrugere" samt virksomheder der skal bruge platformen var usikre på fremtiden, og så manglende åbenhed som en trussel.
Det har Sun gjort noget ved, og endda en hel del, hvilket selvfølgelig er af det gode, ikke bare for Java, men så sandelig også for dem som hænger i .NET verdenen, nu hvor M$ for nogle år siden begyndte af give Express versioner af deres udviklingsmiljøer væk.
Det skal heller ikke være nogen hemmelighed at IBM med eclipse projektet er gået foran og har presset enormt mange på det her område.
Senest har Oracle ved overtagelsen af BEA, gjort licenserne for brug under udvikling gratis (før skulle man købe licenser til BEA produkterne hvis man da havde været så venlig overfor BEA at vælge deres platform til at drifte ens systemer). BEA bedagede måde at drive forretning på, svarer i virkeligheden til at købe tøj af din virksomhed med deres logo på - altså selv at betale for at reklamere for et kommercielt produkt eller virksomhed.

En lille rettelse i dit indlæg går du hen og beskriver Java som et proprietært produkt, og det kan vi ikke være uenige om, men det var som proprietær teknologi diskussion startede.

Jeg er samtidigt enig i at IPR er noget så vigtigt at få gjort klart, for det er det som handles mellem virksomheder i dag (software implementeringer har ringe økonomisk værdi på lang sigt - det har OSS miljøet sørget for, eller måske rettere FOSS miljøet).
Dog synes jeg at jeg kan læse af diskussionen af Open Standards begreb definitionen af Wikipedia, at man gerne vil have både ISO, OASIS m.fl. fjernet fra listen, da de i mange sammenhæng ikke kan anses for åbne, pga. netop deres holdning til IPR. En virksomhed der starter et standardiseringsprojekt under ISO/OASIS kan beholde sine IPR (i form af patenter), dog skal de under standardiseringsarbejdet afgive dem royalty frit, men det forhindre dem ikke i at begynde at opkræve økonomisk vederlag for patent licensering efter standarden er vedtaget.
Jeg er så uvidende om det også gælder OOXML, men det gælder i hvert fald i følge ISO/OASIS egne udsagn.

Men IPR er en helt anden og enormt vigtig debat, inkluderet selvfølgelig de "frygtelige" patenter, som kan være en hindring for fremskridt.

Nå men grunden til at jeg farede op, var sådan set bare for at gøre op med den myte der stadig ligger over Java (og sådan set også Sun), som lukket og proprietær.

Nå men vi fik da hinanden til at læse lidt op på tingene og udvidde hinandens horisont, det er da altid godt :-)

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