Lækket mail: ODF og OOXML er begge på ekspertudvalgets liste

Der er jo ingen andre der kan implementere denne "standard" uden hjælp og ressourcer fra Microsoft.

Fail.

Hvis ekspertudvalget lader sig tage til takke med den implementering, så er alt arbejdet da spildt.

Det var da en overraskelse.

Not.

Hej Morten,

Der er jo ingen andre der kan implementere denne "standard" uden hjælp og ressourcer fra Microsoft.

Det går da efterhånden meget godt for produkter som TextMaker, Kingsoft Office og Google Docs?

Jeg kender intet til TextMaker eller Kingsoft Office, men gælder det ikke for Google Docs, at det kun er i stand til at fremvise et OOXML dokument?

Googles seneste udmelding fastslog jo, at det kun var Document Viewer komponentet, der understøttede OOXML.

Det er faktisk præcist på klokkeslettet et år siden, at Bardenflet og Bojsen sidst gik i medierne CW og V2 med dobbelt- budskabet; Nu skal vi ikke lade snakken drukne i ligegyldig ævl om dokumentformater og diskussioner om strict/transitional, men det er meget vigtigere hvordan vi får vores sundhedsvæsen og skolebørn til at bruge word så hurtigt som muligt.

Mon timingen bliver lagt efter folketingets arbejde, eller det bare er en sød tradition at lukke årets korteste måned med?

Hej Michael,

Jeg kender intet til TextMaker eller Kingsoft Office, men gælder det ikke for Google Docs, at det kun er i stand til at fremvise et OOXML dokument?

Jo - det er vist korrekt.

Hvis Kingsoft Office er den kinesiske openoffice klon, så er det yderst begrænset hvor godt den virker, siger en udstationeret kammerat. Grænsende til nærmest ikke. Jeg har bedt ham om at lave et indlæg, for de har vist testet den af flere gange.

Mht Textmaker, så er understøttelsen også begrænset til en readonly viewer. Ihvertfald ifølje
http://en.wikipedia.org/wiki/TextMaker

Men OOXML/T er jo ikke en åben standard?

Hej Allan,

Hvis Kingsoft Office er den kinesiske openoffice klon, så er det yderst begrænset hvor godt den virker, siger en udstationeret kammerat. Grænsende til nærmest ikke. Jeg har bedt ham om at lave et indlæg, for de har vist testet den af flere gange.

Jeg har ikke testet den selv, men fik den demonstreret i Beijing af dem, da de deltog i OOXML-mødet i december 2009.

:o)

Hej Finn,

Men OOXML/T er jo ikke en åben standard?

Er den ikke?

Jeg har ikke testet den selv, men fik den demonstreret i Beijing af dem, da de deltog i OOXML-mødet i december 2009.

Og hva var resultatet? Jeg skal nok poste resultat/kommentar fra min ekspat-ven hvis der kommer et.

Hvad med textmaker? Har du prøvet den og har den mere understyttelse end en readonly viewer?

http://itmanagement.earthweb.com/osrc/article.php/12068_3923351_2/OpenOf...

... så den vil kunne bruges som åben referenceimplementation for både ODF og OOXML, hvis/når der er uklarhed omkring tolkningen af standarderne.

Hej Allan,

Og hva var resultatet?

Det så godt ud - jeg kan ikke huske, om vi fik demonstreret "Gem".

Jeg skal nok poste resultat/kommentar fra min ekspat-ven hvis der kommer et.

Det vil være fedt - så opdaterer jeg den test jeg lavede engang ifbm "RM Standardbrev 2s"-artiklerne.

Jeg må medgive Jesper Lund at ISO29500.4 er en "åben" standard. Eller rettere sagt en ISO standard. "åben" er vistnok ukendt land.

Men det fjerner ikke den idiotiske ide om at lave en standard så den passer til fortidens synder. Konvertering af dokumenter til en standard ville være så absolut at foretrække fremfor at lave noget som i ISO beskrivelsen står som " To maintain backward
compatibility, all VML namespaces defined in ISO/IEC 29500 maintain the legacy namespace structure used by
the existing corpus of binary documents.". Det svaret til kommunernes lokalplaner som lovliggør ulovligt opførte bygninger. Først opfører vi os tåbeligt og så¨får vi politikerne til at gøre vores opførsel til en god ide.

Hej Niels,

Men det fjerner ikke den idiotiske ide om at lave en standard så den passer til fortidens synder.

Jow, men ude i den virkelige verden er det blot ikke en mulighed. For eksempelvis ODF er det bare ikke en mulig løsning at droppe al funktionalitet, der enten i dag er dubleret eller som er der fordi OOo gjorde det på den måde engang ... selvom man er blevet klogere i dag. For det ville have som konsekvens, at

1) Ældre dokumenter er ikke længere valide ifht den "nye standard" og

2) Applikationer vil crashe for et godt ord, når de møder de ting, der er enten fjernet eller modificeret.

Eneste realistiske måde er faktisk at gøre det vi gjorde med OOXML-S, nemlig lave et (teknisk) clean cut og danne en helt ny dokumenttype med nye namespaces etc. Konsekvensen af det er jo så, at man må sluge den kamel, at der går endnu nogle år før denne "rene" variant bliver implementeret konkret i kontorpakkerne. Indtil da må man nøjes med den "gamle" måde.

Hvad med textmaker? Har du prøvet den og har den mere understyttelse end en readonly viewer?

Du kan læse mere om Textmaker til Linux på denne adresse:
http://www.softmaker.com/english/ofl_en.htm

Jeg har selv licens til Textmaker på Windows, men bruger det desværre ikke så ofte. Jeg har imidlertid indtryk af, at den har ret god read/write-understøttelse af en eller anden form for .docx - af producenten defineret som følger:

Microsoft Word 2010 und 2007: In addition to the DOC file format from Word 2003 and before, TextMaker now faithfully reads and writes the modern DOCX format of Microsoft Word 2010 and 2007. With that, the barriers to exchanging documents are gone.

When you receive documents from colleagues or customers, you want to edit them with your office suite. That's why SoftMaker Office reads and writes Word, Excel, and PowerPoint files with highest fidelity. You can even set your default file types to "Word", "Excel", and "PowerPoint", and never worry about exchanging documents again!

InfoWorld magazine says: "SoftMaker Office shows superior compatibility with Microsoft Office formats, while OpenOffice.org 3.1 falls flat."

TextMaker also supports the open document standard OpenDocument, making it compatible with OpenOffice.org. In addition, SoftMaker Office exports documents, worksheets, and presentations to PDF format.

@Jesper

I min optik ville den rigtige løsning så være at gøre ISO29550.1 (OOXLM/S) til en standard, og gøre ISO29500.4 til et værktøj til at håndtere eller konvertere gamle dokumenter.

Når vi skal vælge vores standarder til dokumentformater er den vigtigste grund at det skal være muligt at udveksle dokumenter mellem forskellige platforme/brugere/aktører. At vælge noget som en standard ud fra arkæologiske årsager forekommer mig at være en noget søgt forklaring.

Konsekvensen ved det valg man gør er at det er muligt for en aktør i en dokumentudveksling (f.eks staten) at forlange at andre aktører (f.eks borgerne) også kan læse disse gamle dokumenter. I stedet ville et valg af 29500.1 tvinge staten til at konvertere dokumenter således at de ikke indeholdt binære referencer eller historiske referencer , når staten kommunikerede med borgerne.

Hej Nils,

At vælge noget som en standard ud fra arkæologiske årsager forekommer mig at være en noget søgt forklaring.

Men det er jo heller ikke det man har gjort i ekspertudvalget. Man har valgt OOXML-T fordi det er den, der er implementeret (hvis den lækkede email står til troende).

I stedet ville et valg af 29500.1 tvinge staten til at konvertere dokumenter således at de ikke indeholdt binære referencer eller historiske referencer , når staten kommunikerede med borgerne.

Jo - men diskussionen af "legacy" i OOXML er totalt overkill og uden proportioner.

For det første:
Den del af OOXML-T, der er "ren legacy" er reelt lille. Set i det store billede er det ikke voldsomt og set i de dokumenter, der genereres af programmer i dag, så er det ganske få ting, der reelt kommer i spil. Reelt er størstedelen af "OOXML-T" én ting - nemlig VML.

For det andet:
"Legacy"-delen af OOXML er allerede implementeret i OOo i dens DOC-understøttelse. Der er fx fin understøttelse for VML i OOo.

For det tredje:
Der er ingen "binære referencer" i OOXML-T.

:o)

@Jesper

Du argumenterer på samme måde som de der forsvarer kongehusets beskrivelser i grundloven. "Det betyder ikke noget reelt så det gør ikke noget at det er der".

Min opfattelse af de regler og love vi har er set fra den anden side. Hvis de ikke betyder noget skal de ikke være der, for hvis de regler vi siger "stort set ikke betyder noget" er med, vil de komme til at betyde noget på et tidspunkt.

Så hvis det eneste der er i ISO29500.4 er VML, så er der set fra min plads ikke nogen grund til at vi skal bruge denne ISO. Så kan vi lige så godt sigte mod den rene vare og sige at 29500.1 er standarden og 29500.4 er et hjælpeværktøj til at forstå gamle dokumenter. Men at 29500.4 ikke har noget at gøre i en standard hvor kommunikation med andre er hovedsagen.

Mig bekendt har MS Og Novell i sin tid lavet et strategisk samarbejde. Er det så ikke nærliggende at tro at MS har hjulpet Novell i at implementere OOXML-T? I det tilfælde er det IKKE en uafhængig leverandør der har implementeret OOXML-T.

Implementeret på MAC. Hvis man tænker på den helt dugfriske mulighed for at genne OOXML i LibreOffice så måske, men er den implementering komplet? MS har jo f.eks. ikke lavet en komplet ODF. Har udvalget undersøgt disse forhold? Eller havner vi igen igen i situationen "Det fungerer, men ikke så godt, så du bør alligevel hellere anvende MS software". Det har historien set før.

Hej Nils,

Så hvis det eneste der er i ISO29500.4 er VML

Bare lige som opklaring: .4 er den del af ISO/IEC 29500. Det som ekspertudvalget måske vil godkende er OOXML-T, der spænder over både .1, .2, .3 og .4 .

Så kan vi lige så godt sigte mod den rene vare og sige at 29500.1 er standarden og 29500.4 er et hjælpeværktøj til at forstå gamle dokumenter. Men at 29500.4 ikke har noget at gøre i en standard hvor kommunikation med andre er hovedsagen.

Det er også lidt sådan vi i ISO i vores daglige arbejde med OOXML opfatter det - nemlig at .4 er et "errata-ark" til de andre dele af OOXML. Dette giver sig også udslag i, at der i forordet til .4 står, at denne del nok på et tidspunkt udgår. Men ekspertudvalget skal jo ikke se på den tekniske/redaktionelle opdeling af et standardpapir fra ISO. De skal se på de dokumentformater, der rent faktisk er implementeret i markedet. Og her er der ingen tvivl om, at det giver super mening at godkende OOXML-T men kun med meget venlige øjne skulle give mening at godkende OOXML-S (som verden ser ud nu).

:o)

Jeg kunne godt tænke mig at vide om et format igen kan fjernes fra listen, hvis det nu viser sig at forudsætningerne ikke holder i praksis. Eller er vi så inde i samme situation som med .DOC at man alligevel holder fast i formaterne fordi man nu en gang skal være bagud kompatibel med fortiden?

Det kommer vel desværre næppe som en overraskelse for nogen at udvalget ville komme til den konklusion efter de senere års teater. Det har ligget i kortene fra starten.

Det er korrekt at Microsoft og Novell indgik et samarbejde i 2006 på nogle bestemte afgrænsede områder - og et af dem var netop udveksling af kontordokumenter.

Og jeg er ret sikker på at Novells implementation er baseret på dette sourceforge-projekt som er finansieret af Microsoft:
http://odf-converter.sourceforge.net/

Så ikke alene er Novell blevet betalt for at (forsøge at) implementere docx. Der er desuden ikke tale om en selvstændig implementation.

Og endelig så tror jeg bestemt ikke at implementationen dækker den ISO-certificerede specifikation - men derimod den samme ikke-certificerede version som MS (foreløbigt?) selv har implementeret.

Så det er bestemt tankevækkende at man bruger Novells buggy plugin som argument for at anerkende OOXLML - enhver der har prøvet det vil nok give mig ret i at det snarere burde bruges som argument for det modsatte.

Hej Martin,

Og jeg er ret sikker på at Novells implementation er baseret på dette sourceforge-projekt som er finansieret af Microsoft:
http://odf-converter.sourceforge.net

Novell sidder jo i ISOs arbejdsgruppe for OOXML, og jeg har engang spurgt deres daværende repræsentant om netop dette (Florian Reuter - det er ham, der i dag står bag NOOXML (Native OOXML)). Han forklarede mig, at ikke alene er licensen ikke kompatibel med LibreOffice's men det var også ifølge ham umuligt at genbruge koden i LibreOffice - ganske som heller ikke Microsoft selv bruger ODF-Converter i deres implementering af ODF i Microsoft Office.

Og endelig så tror jeg bestemt ikke at implementationen dækker den ISO-certificerede specifikation - men derimod den samme ikke-certificerede version som MS (foreløbigt?) selv har implementeret.

LibreOffice implementerer OOXML-T (men Leif ved mere om dette, tror jeg)

at OOXML ikke er så elendigt som omfanget (og visse kritikere) antyder.

Tilgengæld er situationen med sikkerhed sådan, at hvis man ønskede at skærpe konkurrencen indenfor kontorpakker, så hed valget ODF alene.

Aktuelt vil man med begge formater komme i den situation at det offentlige (og private) automatisk udelukkende vil bruge MS Office og MS-formatet OOXML. Sikkert i et sådan omfang at der vil være eksempler på offentlige myndigheder, der end ikke aner hvad man skal stille op med en ".odt"-fil.

Hej Thorbjørn,

Tilgengæld er situationen med sikkerhed sådan, at hvis man ønskede at skærpe konkurrencen indenfor kontorpakker, så hed valget ODF alene.

Ja, det er der så nogle af os, der er lodret uenige i.

:-)

Hej Martin,

Så ikke alene er Novell blevet betalt for at (forsøge at) implementere docx. Der er desuden ikke tale om en selvstændig implementation.

Men - hvorfor er det pludseligt et problem at genbruge koden fra ODF Converter? Er det ikke hele formålet med OSS?

Han forklarede mig, at ikke alene er licensen ikke kompatibel med LibreOffice's men det var også ifølge ham umuligt at genbruge koden i LibreOffice - ganske som heller ikke Microsoft selv bruger ODF-Converter i deres implementering af ODF i Microsoft Office.

odf-converter er under en ikke-copyleft, bsd-lignende licens, så det må da være kompatibelt med hvad som helst.

Fra odf-converter-siden på sourceforge:
"Novell's contribution to the ODF Converter project is porting and integration with OpenOffice.org."
http://odf-converter.sourceforge.net/#license

hvorfor er det pludseligt et problem at genbruge koden fra ODF Converter? Er det ikke hele formålet med OSS?

Her diskuterer vi ikke fri/open source software, men åbne standarder.

Hvis en standard skal kunne tages alvorligt, er det normalt et kriterium at der er flere uafhængige implementationer.

Ligesom Microsoft selv mange gange har kritiseret at en del af de mange ODF-implementationer er baseret på samme kode fra OOo - og dermed ikke er uafhængige.

Og det er da mildest talt diskutabelt om Novells implementation er uafhængig.

Men tilsyneladende kræver det ansvarlige udvalg i Danmark ikke at der er flere uafhængige implementationer - det er åbenbart knapt nok et krav at specifikationen er implementeret overhovedet.

Hej Martin,

Fra odf-converter-siden på sourceforge:
"Novell's contribution to the ODF Converter project is porting and integration with OpenOffice.org."

Ups - jeg tog fejl ... beklager :-). Det er noget tid siden jeg snakkede med Florian om det, så jeg skal lige have seneste status fra vores "Nye Florian" i ISO-udvalget, Thorsten Behrens. Jeg skal nok lige vende tilbage med info.

Ligesom Microsoft selv mange gange har kritiseret at en del af de mange ODF-implementationer er baseret på samme kode fra OOo - og dermed ikke er uafhængige.

Men er det paradoksale i dette argument ikke, at vi dermed river gulvtæppet væk under ODF også? For at vælge en standard i Danmark fordrer jo ikke alene, at der er flere, der har implementeret standarden - der skal også være god interop imellem dem.

... og hvis vi fjerner alle klonerne af OOo, så har vi vel reelt disse tilbage (der bliver brugt i Danmark):

Microsoft Office
KOffice
OpenOffice.org

Og interop imellem disse baseret på ODF er bestemt ikke noget at råbe hurra over.

Og så bliver listen pludseligt tom?

... og hvis vi fjerner alle klonerne af OOo, så har vi vel reelt disse tilbage (der bliver brugt i Danmark):

Microsoft Office
KOffice
OpenOffice.org

Og interop imellem disse baseret på ODF er bestemt ikke noget at råbe hurra over.

Og så bliver listen pludseligt tom?

Der er vel også folk i Danmark der bruger Google Docs, Softmaker Office, Abiword, Gnumeric.

Microsofts implementation kan man se bort fra, da de helt forudsigeligt i vanlig stil bevidst har sikret at deres implementation ikke interopererer ordentligt med noget.

KOffice (og Calligra) er et mindre projekt som har befundet sig i en overgangsfase stort set lige siden de skiftede til ODF som standardformat for nogle år siden (portering til KDE4/Qt4, strukturændringer teknisk og projektmæssigt).

I det mindste er der utallige leverandører der har implementeret ODF af egen fri vilje og uafhængigt af hinanden. At en del af dem så har lidt småproblemer med modenheden endnu, skyldes nok mere, at de ikke har de samme ressourcer som verdens største softwarefirma, end problemer med standarden som sådan.

Hej Martin,

Der er vel også folk i Danmark der bruger Google Docs, Softmaker Office, Abiword, Gnumeric.

Google Docs er også en "klon" af OOo, da dens opførsel ligger meget op af samme version af OOo som Symphony brugte --3 brugte.

(men det er reelt blot en detalje i det store billede)

Der er jo også folk ,der bruger VI, Cloud Office etc, men der er ikke så mange af dem i forhold til de andre på markedet. Ekspertudvalget vurderede at de største var de mest relevante og skrev til dem om input. Derfor listede jeg kun dem. At der er andre kontorpakker derude er vel nærmest en tautologi.

I det mindste er der utallige leverandører der har implementeret ODF af egen fri vilje og uafhængigt af hinanden. At en del af dem så har lidt småproblemer med modenheden endnu, skyldes nok mere, at de ikke har de samme ressourcer som verdens største softwarefirma, end problemer med standarden som sådan.

Men så gør du jo diskussionen akademisk, for den bliver løsrevet fra den virkelighed som ekspertudvalget blev sat til at vurdere. Her nytter det jo ikke noget, at man kan fremvise en parade af forskellige implementeringer - hvis interoperabiliteten sutter.

Hvis du insisterer på, at kun antallet af implementeringer gælder (og ikke deres modenhed), så kan du jo kigge på http://en.wikipedia.org/wiki/List_of_software_that_supports_Office_Open_XML, hvor der pt. listes 38 tekstredigeringsprogrammer, 25 regneark og 18 præsentationsværktøjer.

Tror du, at Microsoft har betalt dem alle for at implementere OOXML i deres værktøjer?

Er vi så færdige med at snakke om, hvorvidt OOXML er implementeret uafhængigt af andre end Microsoft?

Er vi så færdige med at snakke om, hvorvidt OOXML er implementeret uafhængigt af andre end Microsoft?

Jeg kunne vel ikke få dig til lige at undersøge hvor mange af dem der kan eksportere OOXML, og hvor mange af disse der ikke har benyttet sig af MS's odf-converter-kode, eller derivater af den, samt om det er den ISO-certificerede specifikation der er implementeret? ;-)

Hej Jesper.

Jeg var ikke helt klar i skrivningen.

Hvis 29500.1 er en delmængde af 29500.4 og komplementærmængden i vid udstrækning er VML...

Men som du selv skriver er 29500.4 et "errata - ark" og ikke en standard, deref også standardens etymologi i navnet transitional/overgang.

Og nej, jeg køber stadigvæk ikke rationalet om at når det nu er der skal det også være fremtidens standard. Så måske er det jeg kritiserer mere ISO's beslutningsmodeller for standardiseringer, mere end den pragmatiske tilgang til eksistensen af mia. af dokumenter som så ikke vil være "standardiserede".

Hej Martin,

Jeg kunne vel ikke få dig til lige at undersøge hvor mange af dem der kan eksportere OOXML, og hvor mange af disse der ikke har benyttet sig af MS's odf-converter-kode, eller derivater af den, samt om det er den ISO-certificerede specifikation der er implementeret? ;-

Synes du ikke, at du griber efter halmstrå nu?

En skimning af listen over teksteditorer lugter af, at omkring halvdelen af produkterne kan eksportere OOXML.

Om de gemmer i ISO-standarden er vel ikke så relevant? Jeg tror faktisk aldrig, at der er nogen applikationer, der har kunnet gemme i den ISO-standardiserede ODF (da ODF 1.0 blev ISO-godkendt var man allerede på ODF 1.1 i OOo).

Hej Nils,

Hvis 29500.1 er en delmængde af 29500.4

.1 er ikke en delmængde af .4 . .1 er en delmængde af ".1+.2.+.3+.4) ligesom .4 er det.

Og nej, jeg køber stadigvæk ikke rationalet om at når det nu er der skal det også være fremtidens standard.

Det er der vel heller ikke nogen, der har sagt?

Om de gemmer i ISO-standarden er vel ikke så relevant? Jeg tror faktisk aldrig, at der er nogen applikationer, der har kunnet gemme i den ISO-standardiserede ODF (da ODF 1.0 blev ISO-godkendt var man allerede på ODF 1.1 i OOo).

Apropos at gribe efter halmstrå, så skulle man måske feje for egen dør.

Jeg har da lige gemt i ODF 1.0 på min OOo.

Hej Ayhan,

Jeg har da lige gemt i ODF 1.0 på min OOo.

Hvilken version?

Hvilken version?

Hvilken betydning har det?

Desuden har du har ikke svaret på Martin Schlanders spørgsmål - kun undveget.

Du får den lige igen:

Jeg kunne vel ikke få dig til lige at undersøge hvor mange af dem der kan eksportere OOXML, og hvor mange af disse der ikke har benyttet sig af MS's odf-converter-kode, eller derivater af den, samt om det er den ISO-certificerede specifikation der er implementeret? ;-)

Hej Ayhan,

Hvilken betydning har det?

Det har da stor betydning. Der er ingen af leverandørerne, der kan levere en kontorpakke i dag, der gemmer i ODF 1.0 . Jeg kan ikke huske, at jeg i mine OOo-udgaver har haft mulighed for at gemme i ODF 1.0. I OOo har der i mange år stået, at man kan gemme i "ODF 1.0/1.12, men det er reelt sket i ODF 1.1 .

Og jeg har ikke undveget Martins spørgsmål. Ekspertudvalget har dannet sin mening på baggrund af input fra de større leverandører af kontorpakker. Det er nok ud fra tanken om, at det vil være dem, der vil komme til at levere kontorpakke til det offentlige. I forhold til beslutningen synes jeg ikke at det er voldsomt relevant om AbiWord, Gnumeric eller andre med lille udbredelse kan gemme i ODF/OOXML.

Hej Ayhan,

Jeg har da lige gemt i ODF 1.0 på min OOo.

Jeg tænkte på - kunne du ikke lokkes til at smide den ODF-fil op på www.ge.tt eller lignende og lægge link herinde? Det er rigtigt lang tid siden jeg har set en ODF 1.0-fil, så den kunne jeg godt tænke mig at se :o).

Det er rigtigt lang tid siden jeg har set en ODF 1.0-fil, så den kunne jeg godt tænke mig at se

Mig bekendt gemmer Google Docs i ODF-1.0. Eller måske OASIS ODF-1.1. Det er i hvert fald ikke ODF-1.2 draft.

Jesper, du har så travlt med at skabe FUD omkring ODF. Du bør hellere bekymre dig om de endnu større problemer hos OOXML:

»Ingen leverandører har implementeret OOXML efter ”strict conformance class”.«

Det nedenstående udklip fra itpol.dk beskriver farcen kort og præcist:

Af hensyn til bagudkompabilitet er der beskrevet en OVERGANGSversion af OOXML (Transitional) i ISO29500. Transitional er identisk med den af ISO forkastede ECMA version af OOXML. Det er kun denne forkastede transitional/ECMA version der er ved at være implementeret i MS's kontorpakke 2010.

Den ISO-godkendte dokumentstandard er selvfølgelig ikke en overgangversion, men OOXML Strict. Men Strict er ikke implementeret og stadig under revision. Altså har Microsoft bare ikke nogen kontorpakke der kører ISO-godkendt standard.

Nu prøver Microsoft at bilde os og politikerne ind at den forkastede ECMA=Transitional i virkeligheden er den ISO-godkendte standard, og MS derfor har en kontorpakke der kører en ISO-godkendt standard. Jasper Bojsen, Microsoft, påstår at de 5600 siders beskrivelse af Strict er en vision uden praktisk anvendelighed!!! [1] Det er og bliver humbug. Det er patetisk og latterligt.

ODF blev ISO-godkendt for 3-4 år siden og er for længst implementeret. Microsoft er bare bagud.

Kilde: http://www.itpol.dk/node/367

Hej Ayhan,

JEsper, du har så travlt med at skabe FUD omkring ODF.

FUD? Jeg påpeger ikke andet end at der ikke i dag fra de store leverandører leveres kontorpakker med r/w-understøttelse for ISO/IEC 26300 (ODF 1.0). Det kan sgu da ikke være FUD - folk som Rob Weir, Leif Lodahl og andre har påpeget dette masser af gange.

Få venligst din paranoia under kontrol.

et nedenstående udklip fra itpol.dk beskriver farcen kort og præcist:

Du bør vælge dine kilder med lidt mere omhu - ellers ender du med at fremstå som en énøjet ODF fanboy / OOXML-basher. IT-Pols dækning af "dokumentformatkrigen" har fra dag ét være tendentiøs - for nu at bruge et mildt ord. IT-Pol kan lave mange gode ting - men de er uvidende amatører, når det kommer til OOXML og ODF.

Fra det du citerer kan jeg oplyse om, at følgende før sig gældende:

"Af hensyn til bagudkompabilitet er der beskrevet en OVERGANGSversion af OOXML (Transitional) i ISO29500. [b]Transitional er identisk med den af ISO forkastede ECMA version af OOXML.[/b]"

Det er forkert (med fedt markeret).

[b]Det er kun denne forkastede transitional/ECMA version der er ved at være implementeret i MS's kontorpakke 2010[/b].

Det er forkert (med fedt markeret).

[b]Den ISO-godkendte dokumentstandard er selvfølgelig ikke en overgangversion, men OOXML Strict.[/b]

Det er forkert (med fedt markeret).

Men Strict er ikke implementeret [b]og stadig under revision[/b].

Det er forkert (med fedt markeret).

[b]Altså har Microsoft bare ikke nogen kontorpakke der kører ISO-godkendt standard.[/b]

Det er forkert (med fedt markeret).

"Nu prøver Microsoft at bilde os og politikerne ind at den forkastede ECMA=Transitional i virkeligheden er den ISO-godkendte standard, og MS derfor har en kontorpakke der kører en ISO-godkendt standard. [b]Jasper Bojsen, Microsoft, påstår at de 5600 siders beskrivelse af Strict er en vision uden praktisk anvendelighed!!! [1][/b]

Det er forkert hvad Jasper Bojsen siger (i mine øjne), men her har IT-Pol så faktisk ret.

:o)

Jeg har påpeget de massevis af faktuelle fejl i deres dækning et utal af gange, men de har ikke ønsket at skrive noget, der var i bedre overensstemmelse med sandheden.

Hvad med den ODF-fil? Vil du ikke smide den op til os?

Det er faktisk meget simpelt.

Men Strict er ikke implementeret og stadig under revision.

Ergo:

Altså har Microsoft bare ikke nogen kontorpakke der kører ISO-godkendt standard.

Alt andet er udenomssnak og pladder.

Hej Ayhan,

et er faktisk meget simpelt.

"Men Strict er ikke implementeret"

Ergo:

"Altså har Microsoft bare ikke nogen kontorpakke der kører ISO-godkendt standard."

Hvorfor lytter du ikke til hvad jeg siger?

Det er [b]faktuelt forkert[/b] at sige, at "Transitional" ikke er "en ISO standard". Strict og Transitional er begge ligeværdige [i]conformance-klasser[/i] indenfor samme ISO-standard 29500:2008.

... og så kan vi tage en snak om, hvorvidt S eller T er bedst, dårligst, idiotisk etc og den tager jeg gerne med dig. Men IT-Pols udsagn er faktuelt forkert, og det siger alt om IT-Pols tendentiøse vinkel til debatten, at teksten stadig står på deres hjemmeside - selvom de gentagne gange er blevet gjort opmærksomme på,at den er forkert.

Det er helt OK at have en politisk holdning til S eller T - men det andet er faktuelt forkert.

Alt andet er udenomssnak og pladder - og det er sådanne udtalelser som dine, der er den primære årsag til, at de politikere, beslutningstagere jeg taler med ruller med øjnene, når talen kommer på udsagn i debatten herinde.

... og dermed arbejder du vel egentlig imod dit eget ønske?

vad med den ODF-fil? Vil du ikke smide den op til os?

Det er faktisk ikke så svært.

Pkt. 1: Det er faktuelt forkert at sige, at "Transitional" er "en ISO standard". Strict og Transitional er begge conformance-klasser indenfor samme ISO-standard 29500, men er vidt forskellige på centrale punkter:
http://horlyck.dk/Jens/ISO29500-def.htm

Pkt. 2: Formålet med Transitional iht. standarden:

The intent of this Part is to enable a transitional period during which existing binary documents being migrated to ISO/IEC 29500 can make use of legacy features to preserve their fidelity, while noting that new documents should not use them.

Pkt. 3: OOXML Strict kan endnu ikke produceres af nogen kontorpakke.

Ergo kan man slutte at OOXML endnu ikke er understøttet af nogen kontorpakke og bør derfor forkastes.

Af ren og skær undren kunne jeg godt tænke mig at høre hvordan at folk generelt uddeler plusser og minusser her på sitet.

Uddeler I ud fra om I mener at det der står beskrevet i indlægget er korrekt eller uddeler I "the youtube way" med angivelse af om I kan lide det I ser, uafhængigt af om det I ser er korrekt?

Jeg har selv altid brugt plusser og minusser herinde til at angive om jeg mener det der står skrevet er korrekt, uanset om jeg så kan lide at det er korrekt eller ukorrekt. Men jeg kan næsten ikke tro andet end at der er mange som bruger tommelfingrene som "kan lide/kan ikke lide" og ikke "korrekt/ikke korrekt", eller er det helt forkert?

Til dette indlæg kan man bruge knapperne til at angive
Tommelfinger ned: Jeg forstår ikke spørgsmålet
Tommelfinger op: Jeg forstår spørgsmålet men ønsker ikke at svare

Hej Ayhan,

Ergo kan man slutte at OOXML endnu ikke er understøttet af nogen kontorpakke og bør derfor forkastes.

Du er nødt til at forstå, at det ikke er mig, IT-Pol eller Jens Hørlück, der bestemmer, om en givet applikation overholder en standard. Det er derimod standarden du skal finde belæg for, om en applikation overholder kravene. Det er heller ikke givtigt som du gør det nu at plukke sætninger ud af specifikationen og tro, at de kan fortolkes ude af kontekst. Du er nødt til at have hele billedet med.

"Kravene" er nedfældet i de såkaldte "conformance classes", hvoraf der er to i OOXML. Disse er 110% ligestillede - der er ikke noget i standarden, der gør den ene mere korrekt end den anden.

Når du så refererer til "scope" i Part 4 i OOXML, så er nøgleordet "should". Dette ord blev valgt meget specifikt i Geneve. Hvis vi havde ønsket, at der aldrig skulle være dokumenter og applikationer, der kunne erklære "conformance" til Part 4s conformance clause, så ville vi ikke have valgt "should". Vi ville have valgt "SHALL" eller ækvivalent slet ikke have standardiseret indholdet i Part 4. Ordet "should" er præcist valgt for at give mulighed for en transitionsperiode men samtidig gjort det klart, at vi i ISO ønsker, at man i fremtiden foirtrinsvist producerer Strict dokumenter.

Vi har faktisk diskuteret netop dette ord tidligere herinde, hvor Gert Agerholm udtalte:

"Når der i en specifikation står "anbefaler" (should, JLS) så er det 100% lovligt at gøre noget andet."

http://www.version2.dk/artikel/16531-the-long-con--odf#headline82400

Så derfor er det [b]faktuelt forkert[/b], når du siger, at Microsoft Office ikke understøtter ISO/IEC 29500, for dokumenter dannet i Microsoft Office er i overensstemmelse med "Transitional Conformance".

Jeg kan ikke forstå, hvorfor du ikke accepterer, at du tager fejl her. Det er lodret forkert, når du siger, at OOXML ikke er implementeret og derfor skal forkastes.

Dine holdninger politiske, og den diskussion tager jeg gerne, men den skal da for pokker ske på et oplyst grundlag, synes du ikke? Du prøver i stedet at kortslutte diskussionen ved at opsætte en præmis, der ikke på nogen måde har rod i virkeligheden.

Hej Henrik,

Uddeler I ud fra om I mener at det der står beskrevet i indlægget er korrekt eller uddeler I "the youtube way" med angivelse af om I kan lide det I ser, uafhængigt af om det I ser er korrekt?

"The Version2-way" er typisk sidstnævnte måde. Det har så den konsekvens, at man dermed kan bruge antallet af minusser til at måle, om man har fat i noget af det rigtige. Dermed bliver antallet af minusser proportionalt med korrektheden af det man skriver ... i hvert fald, hvis man ikke vender røven imod samme mekka som parnasset herinde.

:o)

Det er MS der har valgt at ignorere anbefalingen om fuld understøttelse for OOXML Strict. Det er overhovedet ingen politik i det her, det er en forretningsmæssig beslutning.

Det er ren spin fra din og MS' side at det skulle frivilligt at nøjes med understøttelse for OOXML Transitional.

Ordet "should" defineres som i RFC 2119:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

Ergo skal der være en god grund til ikke at implementere Strict. Hvad svarer en blogger fra MS?

In the case of Office 2010’s use of Transitional, we have decided to prioritize compatibility and interoperability with existing implementations, because we believe this is in the best interest of our customers. So although the conformance clause says that Transitional “should not” be used for new documents, we have decided that the needs of customers, combined with the realities of the current document format ecosystem (most existing implementations are Transitional, recent major changes to the Strict namespaces), make Transitional the right choice. We will continue to update our plans in response to feedback from customers, other implementers, and the standards community going forward.

En masse dårlige undskyldninger.

Jesper, drop dit spin om at en holdning om hvorvidt Strict skal være implementeret eller ej er politisk begrundet. Det har overhovedet ingen politisk relevans. Af standarden fremgår det tydeligt at en udeladelse af Strict skal være velbegrundet og bør undgås.

Undskyldningen om at det er bedst for kunderne er næsten ligeså god som at Office skulle være godt for de svage børn:
http://www.computerworld.dk/art/50156/microsoft-open-source-kan-ramme-de...

Hej Ayhan,

Det er overhovedet ingen politik i det her, det er en forretningsmæssig beslutning.

Nemlig - og det er en forretningsmæssig beslutning som Microsoft har fuld "ret" til at lave ifht conformance-krav i OOXML. På samme måde har ORACLE fuld ret til ikke at have implementeret understøttelse for hele ODF. At overholde en specifikation er ikke "alt eller intet".

Det er ren spin fra din og MS' side at det skulle frivilligt at nøjes med understøttelse for OOXML Transitional.

Jamen så må du jo fortælle, hvor du kan finde belæg for dette i specifikationen. Det er ikke raketvidenskab.

Ordet "should" defineres som i RFC 2119:

Det gør det faktisk ikke, og det ville være rart, hvis du rent faktisk forsøgte at finde de [b]rigtige[/b] svar end blot de svar, der stemmer overens med din holdning.

"SHOULD" defineres i ISO-standarder jvf ISO/IEC Directives Part 2, Annex H. Her kan du se, at der for "SHOULD" står:

"SHOULD not":

[i]it is not recommended that[/i]
[i]ought not to[/i]

Tabellens indhold kvalificeres endvidere som:

[i]"The verbal forms shown in Table H.2 shall be used to indicate that among several possibilities one is recommended as particularly suitable, [b]without mentioning or excluding others[/b], or that a certain course of action is preferred [b]but not necessarily required[/b], or that (in the negative form) a certain possibility or course of action is deprecated [b]but not prohibited[/b]."[/i]

(min fremhævning)

Er det klart for dig nu?

Men ... hvis vi et øjeblik legede, at du havde ret, så vil dit argument om at anbefalinger i en standard var normativt påkrævede at implemnentere også rive tæppet væk under OpenOffice.org og dermed hele økosystemet omkring ODF for OOo ville aldrig nogensinde have "implenenteret ODF".

Er det virkeligt det du ønsker? Nogle gange føler jeg, at "jeres" foragt for OOXML er så stor, at I ingen midler skyr for at invalidere den - også selvom ODF i samme ombæring dræbes også.

"Operationen var en succes - men patienten overlevede ikke".

Det virker meget mystisk på mig.