ODF – et åpent alternativ?

Martin Bekkelund er en aktiv pådriver for bruk av ODF og åpne standarder, og en like aktiv motstander av OOXML og lukkede standarder. For en stund siden hadde han et innlegg i sin blogg hvor han skrev litt om hva åpne standarder innebærer og fordelene ved å bruke en åpen standard som for eksempel ODF. La det være sagt med en gang: Jeg er tilhenger av åpne standarder og bruk av ODF og andre åpne formater. Det jeg er litt i tvil om er om ODF faktisk gir de fortrinnene Martin Bekkelund hevder i sin blogg. Han lister opp følgende under overskriften «Hvilke fortrinn gir bruk av åpne standarder?»:

  • Leverandøruavhengighet
  • Sikkerhet mot uønskede endringer i standarder som benyttes
  • Mer robuste standarder — hvor er logikken i at et tekstdokument skal være virusspreder?
  • Ingen kostnader tilknyttet bruk av åpne standarder
  • Bedre, raskere og sikrere integrasjon mot andre systemer
  • Interoperabilitet
  • Økt konkurranse i markedet
  • Økt sikkerhet — du vet hva standarden inneholder og ikke minst ikke inneholder
  • Gjenbruk av komponenter som allerede er oppfunnet

La oss se litt på hvor ODF ligger i dette bildet.

  • Leverandøruavhengighet

Det finnes per i dag flere fullverdige implementasjoner av ODF, både for Mac, Linux og Windows. De fleste er basert på OpenOffice.org. Windowsbrukere kan velge mellom blant annet OpenOffice.org (gratis), Lotus Symphony (IBM, gratis), OpenOffice 2 Novell Edition (Novell) og StarOffice (Sun). I tillegg finnes det implementasjoner som Google Docs som inneholder begrenset funksjonalitet. Joda, leverandøruavhengigheten er for så vidt ivaretatt samtidig som de fleste implementasjoner er basert på samme utgangspunkt (OpenOffice.org).

  • Sikkerhet mot uønskede endringer i standarder som benyttes

Dette punktet er relativt meningsløst om man ikke definerer hva «uønskede endringer» er. En standard som er godkjent i ISO er under ISO sin kontroll og det er de som avgjør hvem som skal vedlikeholde og videreutvikle standarden. Det blir uansett ingen «uønskede endringer» om ikke ISO godkjenner det. For ODF sin del er det forøvrig Oasis som har ansvaret med å vedlikeholde og videreutvikle standarden.

Man kan også sette dette punktet på hodet: Hva med sikkerheten for ønskede endringer? Bør man ikke kunne være sikker på at de endringene som er ønskelige også blir utført? Her får ODF straks litt trøbbel. Sun har nemlig en lang rekke patenter knyttet til ODF. I et såkalt IPR statement har de frasagt seg alle patenrettigheter knyttet til nåværende versjon av ODF og fremtidige versjoner som de selv er med å utvikle. Det vil si at Sun har mulighet til å blokkere alle fremtidige endringer som de selv mener er «uønskede».

  • Mer robuste standarder — hvor er logikken i at et tekstdokument skal være virusspreder?

Alle dokumenter som inneholder eller linker til kjørbar kode (makroer) kan potensielt inneholde virus. Sånn sett er det ingen forskjell på ODF og andre dokumentformater. Det har ved flere anledninger vært demonstrert at OpenOffice.org også kan rammes av makrovirus, på samme måte som konkurrerende programvare:

http://arstechnica.com/news.ars/post/20070522-cross-platform-openoffice-macro-virus-revealed.html 

Som det står i konklusjonen: (…) open-source software products can be targeted just as easily as proprietary products when security isn’t treated as a primary consideration.

Nå kan det selvsagt innvendes at makroer ikke er en del av dokumentformatet ODF, og det er selvsagt korrekt, men det er ikke noe annerledes enn det er med OOXML.

  • Ingen kostnader tilknyttet bruk av åpne standarder

Det er ikke noen kostnader tilknyttet bruk av formatet ODF. Hvem som helst kan implementere formatet fritt, på samme måte som OOXML. Det finnes pr i dag to gratis fullverdige alternativer for å lage og lese ODF-filer på Windows-platform: OpenOffice.org og Lotus Symphony. Sistnevnte er foreløpig kun tilgjengelig i beta-versjon.

  • Interoperabilitet

Med interoperabilitet menes her antakelig at filer laget i en applikasjon som støtter en bestemt standard kan åpnes og redigeres i en annen applikasjon som støtter samme standard. Altså: et regneark laget i OpenOffice.org skal kunne åpnes og redigeres i Lotus Symphony eller KOffice uten tap av innhold, formatering og funksjonalitet. Som jeg har vist til tidligere er ikke dette uproblematisk. Nå skal det sies at dette forsøket ble gjort med en beta-utgave av Lotus Symphony og vi får håpe de får fikset opp dette til den endelige utgaven.

De som har tilgang til både OpenOffice.org og Lotus Symphony kan jo gjøre et par tester selv for å se hvor interoperable de er. Start OpenOffice.org Writer og lag en tegnet figur i et dokument, for eksempel et rektangel. Kopier figuren og lim den inn i et Lotus Symphony-dokument. Neste forsøk: lag en tegnet figur i Lotus Symphony-dokumentet, for eksempel et rektangel. Høyreklikk på figuren og velg Formegenskaper -> Skråstilling og hjørneradius. Sett skråstillingen til 45 grader, klikk OK, kopier figuren og lim den inn i et OpenOffice.org-dokument. De samme problemene oppstår selvsagt om du lagrer filen i en applikasjon og åpner den i den andre applikasjonen. Den leverandøruavhengigheten vi så på tidligere viser seg foreløpig å være mer på papiret enn i praksis.

Et annet og større problem er at ODF 1.0 (som er den versjonen som er ISO-godkjent og brukes av OpenOffice.org) mangler formeldefinisjoner. Det er altså ingen felles oppskrift på hvordan formler og funksjoner skal settes opp og det er opp til applikasjonen å tolke hvordan dette skal gjøres i et regneark. Dette kan føre til at utregninger som er gjort i en applikasjon kan gi helt andre resultater enn utregninger gjort i en annen applikasjon, til tross for at de bruker samme filformat.

Det har vært arbeide i tre år med å inkludere formeldefinisjoner i ODF men det er fortsatt ikke klart når dette vil være på plass.

  • Økt konkurranse i markedet

Det finnes som nevnt flere applikasjoner som har ODF som standard lagringsformat. De fleste er basert på OpenOffice.org som regnes som referanseimplementasjonen. Konkurransen har imidlertid ikke vært all verden så langt. Det er først i det siste Lotus Symphony har kommet opp som en seriøs konkurrent på Windows-platformen.

  • Økt sikkerhet — du vet hva standarden inneholder og ikke minst ikke inneholder

Dette er et godt poeng og det er en stor fordel med standardiserte formater. Det er jo også et godt argument for at OOXML bør standardiseres i ISO.

  • Gjenbruk av komponenter som allerede er oppfunnet

ODF gjenbruker en lang rekke eksisterende standarder, som for eksempel MathML, SVG og XLink. Det viser seg imidlertid at ODF ikke følger SVG-standarden og at OpenOffice.org ikke bruker SVG i det hele tatt men et eget internt tegneformat (det kan forklare problemene med tegningene jeg viste til tidligere). Bruken av MathML er heller ikke uproblematisk i OpenOffice.org. Igjen viser dette at valgfriheten og leverandøruavhengigheten er mer illusorisk enn reell.

Advertisements

20 thoughts on “ODF – et åpent alternativ?

  1. Jesper Lund Stocholm

    Fredrik,

    Lige en kommentar/rettelse:

    Du linker til mit indlæg om MathML (tak for det) og bruger det som argument for, at OpenOffice.org ikke implementerer MathML korrekt. Jeg er uenig i den konklusion. Konklusionen min er, at OpenOffice.org implementerer MathML korrekt, men at der er nogle begrænsninger i implementeringen og nogle quirks som man skal kende til for at kunne skabe den ønskede interop med OpenOffice.org :

    1. OpenOffice.org bruger en specifik DOCTYPE til MathML-«klumpen». Det skal man vide for det står ikke i ODF eller MathML.

    2. OpenOffice.org har ikke implementeret alle MathML-entities (som fx Pi) og derfor kan man ikke bruge «normale» entities som π eller lignende.

    Svar
  2. Fredrik E. Nilsen Innleggsforfatter

    Hei Jesper,

    Takker for korreksjonen, da skal jeg rette opp det. Grunnen til at jeg skrev det var denne setningen fra din blogg: (…) errors in the implementation of OpenOffice.org where MathML is clearly not implemented correctly.

    Svar
  3. Jesper Lund Stocholm

    Hej Fredrik,

    Aah – det kan jeg godt se. Jeg har rettet min artikel til:

    «Most of the things I have shown above are imo due to errors in the implementation of OpenOffice.org where MathML is clearly not implemented sufficiently.»

    http://idippedut.dk/post/2008/01/Do-your-math—ODF-and-MathML.aspx

    Som jeg også skriver, så er MathML-fragmenterne i OOo jo valide MathML-fragmenter, så de sådan set fine nok. Men OOo-drengene har fx valgt ikke at implementere alle MathML-entiteterne som fx π [& pi ;] og andre, så derfor halter interop, hvis man bruger MathML, der er lavet af andre værktøjer.

    Tak for input.

    🙂

    Svar
  4. Tilbaketråkk: Alf Ivar online » Valg av programvare i skolene

  5. Einar Stavleik

    Hei Fredrik.

    Jeg synes argumentasjonen din er litt feilrettet. Du prøver tilsynelatende å tilbakevise/teste påstandene til Martin om fordelene med bruk av åpent dokumentformat. Eller?

    På punktene du går igjennom (hvor jeg er delvis uenig i konklusjonen/betraktningsmåten du lander på for enkelte av dem, men det kan vi se bort ifra i denne omgang) så finner du tilsynelatende mangler eller svakheter ved en rekke ting: enten er det ODF 1.0-spesifikasjonen du mener har mangler, eller så er det en implementasjon i f.eks. OpenOffice.org eller Lotus Symphony. Spør du meg gjelder det å tydelig skille mellom prinsippielle argumenter for bruk av reelt åpne/frie dokumentformater vs. en spesifikk dokumentspesifikasjon vs. et sett med (forsøk på) implementasjon av denne dokumentspesifikasjonen (og andre spesifikasjoner).

    Spør du meg så roter du litt. Om implementasjonen i OO.o ikke er helt i henhold til ODF 1.0 (enten fordi OO.o har gjort noen valg der ODF 1.0 har mangler og ikke spesifiserer tilstrekkelig — heldigvis er ODF til forbedring) eller av andre årsaker, så trenger ikke det bety at prinsippet med ODF er dårlig. Ofte må man ha tre forsøk før man slår home-run — alt går ikke på første forsøk, selv om man skulle ønske det.

    Dra gjerne paralleller til HTML og WWW. De ulike webstandardene er rimelig spesifikke og rett fram å implementere, kun de nyeste mest avanserte kan by på litt problemer. Videre har man en rekke nettlesere som gjør så godt de kan på å rendre web-sider så korrekt som mulig. Det er da viktig at implementasjoner legger til proprietære utvidelser eller foretar alternative tolkninger som bryter/utvider standarden dersom det er mulig å unngå. Vi kjenner alle til Internet Explorer. Tilsvarende er det en fordel at OO.o og andre ODF-implementasjon strammer inn, men dette tar litt tid og man er avhengig av flere implementasjoner for å korrigere hverandre. Selv om nettleserne ikke alltid er helt enige, så betyr ikke dette at HTML er elendig eller at vi bør forlate prinsippet med en åpen spesifikasjon for WWW.

    PS: Forresten så skriver du blant annet:

    > > * Økt sikkerhet — du vet hva standarden inneholder og
    > >ikke minst ikke inneholder
    >
    > Dette er et godt poeng og det er en stor fordel med
    > standardiserte formater. Det er jo også et godt argument
    > for at OOXML bør standardiseres i ISO.

    Da er dette også et argument for mitt hjemmesnekrede «Einars Open SuperXML»-format _også_ bør standardiseres i ISO, da eller? Jeg regner med at dette er nok til at du ser intetsigelsen i argumentet ditt 😉

    Svar
  6. Fredrik E. Nilsen Innleggsforfatter

    Hei Einar,

    Mitt poeng er enkelt: Martin Bekkelund lister opp en del fortrinn ved å bruke åpen standarder som ODF. Jeg ønsker å sjekke om ODF virkelig gir disse fortrinnene, og i hvilken grad et konkurrerende format gjør det samme. Martin Bekkelund har jo ved flere anledninger referert til OOXML som et lukket og proprietært format.

    Jeg er altså ikke i mot åpne standarder og mener ikke at prinsippet om ODF er dårlig, tvert i mot. Jeg deler bare ikke Martin Bekkelunds syn om at ODF gir alle de fortrinnene han lister opp, og heller ikke hans syn om at OOXML er et lukket og proprietært format.

    Når det gjelder det siste punktet ditt vil du antakelig frem til at OOXML ikke bør standardiseres i ISO siden vi allerede har ODF. Det er vanlig med delvis overlappende standardiserte formater og forskjellene i ODF og OOXML er så store, både i innhold, struktur og formål, at det på nåværende tidspunkt forsvarer to standarder. Hvis «Einars Open SuperXML»-format har egenskaper som ikke dekkes av eksisterende formater står du selvsagt fritt til å forsøke å få standardisert dette. 😉

    Svar
  7. Brynjard Øvergård

    Unskyld meg, men skyter du ikke deg selv kraftig i foten med dette utspillet?

    I denne «artikkelen» tar du frem mange av argumentene som brukes for å forsvare åpne standarder (eller mer presist ODF, det er ikke noen særlig diskusjon om åpne formater generelt) og prøver å «tilbakevise» disse påstandene med dine egne erfaringer (som ganske tydelig er veldig begrenset og kraftig påvirket av dine egne meninger). I din iver etter å bevise hvorfor ODF ikek er løsningen på alt, og at dette formatet også har sine problemer kommer du i vilfarelse til å også rette skyts mot OOXML!

    *Leverandøruavhengighet:
    Du nevner at de aller fleste implementasjonene er basert på referanseimplementasjonen i OOo. Noe som i og for seg er riktig, men du glemmer helt av å si at det finnes over 10 andre mer eller mindre fullverdige implementasjone som _ikke_ er direkte relatert til OOo sin implementasjon.
    OOXML har vært en ECMA standard i 2 år, og hittil har ikke noen klart å implementere noe som klarer å lese et word dokument engang! Det finnes med andre ord absolutt null leverandøruavhengighet med OOXXML, mens ODF vrimler av forskjellige GPL og proprietære implementasjoner

    *Sikkerhet mot uønskede endringer
    Her tar du frem Sun’s patenter som de har med i ODF. Du glemmer helt å nevne alle patentene MS har med i OOXML, og at de på ingen måte har frasagt seg disse. Og i tilfelle man skulel implementere OOXML og snuble over patenter som berøre gammle Word implementasjoner som ikke nødvendigvis er dekket av OOXML er man i alle fall ute på glattisen.
    På toppen av det hele har MS satt som «krav» av OOXML _bare_ skal kunne oppdateres av dem selv, og at ISO i praksis må føye seg etter deres ønsker. Det lukter det ikke «uønskede endringer» av, neeeida….

    *Mer robuste standarder …
    Klart, alt som kan kjørs kan være et virus, men en 6000 siders dårlig skrevet dokumentasjon er lettere å gjøre feil i enn et 700 siders dokument som har blitt brukt utallige årsverk fra forskjellige leverandører for å kvalitetssikre. Potensialet for feil i OOXML er veldig mye større, og at det er funnet feil i ODF betyr bare at det antageligvis skjuler seg langt flere feil i en OOXML implementasjon.

    *Ingen kostnader…
    LGPL biblioteker er så billig så man kan få det, koster deg 0 kr netto. Når ble foresten Office gratis, er det noe jeg ikke har fått med meg?

    *Interoperabilitet
    Her går du på ei virkelig blemme. Det er ikke enkelt å gjøre det samme i forskjellige programmer med forskjellige mål og forskjellige implementasjoner, selv om man har en godt skrevet spesifikasjon å forholde seg til. HTML har visst dette ganske tydelig (IE driter jo stort sett i spec’ene, men selv de som prøver å følge dem er det støtt og stadig uenigheter som dukker opp). Dette er med andre ord ikke helt enkelt å få til, og det krever mange års innsats og fintunig i de forskjellige programmene.
    Og så skal man altså innføre en til spesifikasjon, som er på 6000 sider med dårlig håndarbeid (noe ingen som har prøvd å lese den vil protestere på), som skal ha mye overlappende funksjonalitet, og som selv ikke MS selv gidder å følge til punkt å prikke (ganske langt unna faktisk).
    Det kommer jo å gjøre det hele så mye letter, eller hva?

    *Økt konkuranse i markedet
    Å la den største aktøren standardisere sitt eget format, som ingen andre har klart å implementere og la dem selv bestemme over endringene kommer jo til å gjøre underverker for utsiktene for konkuranse til Office?

    *Gjenbruk…
    ODF gjenbruker tidligere definerte standarder som er skrevet og godkjent av ISO. Mange av dem har vært brukt i årevis, og kommet i mange revisjoner og forbedringer. Alle standardene har et bredt utvalg med impementasjoner, og det finnes referanseimplementasjoner som er LGPL for omentrent samtlige (om ikke alle?)
    OOXML gjenbruker _ingen_ tidligere ISO spesifikasjoner (hvis vi ser bort fra XML da, som de i utganspunktet lagde sine egne «extensions» til men som de fjernet før de lagde ECMA spec’en). Man finner med andre opp _alt_ på nytt, fra tegning av grafikk, til definer av nasjonale tegnsett. På hvilken måte er dette positivt?!

    Kort oppsummert virker det som du ikke helt har tenkt igjennom alle argumentene som brukes for rakke ned på ODF. OOXML er dårligere og værre en værst på alle områdene som nevnes her, uten at det er særlig udypet eller argumentert for eller imot.

    Faktisk er hele denne bloggen en eneste lang fanfare i ensidig argumentasjon for OOXML uten noen form for god argumentasjon annet enn pekere til andre blogger og sitering av hva andre folk har sagt, det er bemerkelsesverdig lite innslag av faktainformasjon, noe som i og for seg er karakteristisk for en blogg. Kort og godt personlige meninger og synsing, og du har tydeligvis bestemt deg for lenge siden at OOXML er det beste som noensinne har skjedd verden, uansett hva slags andre fakta som måtte komme på bordet.

    Ta heller å les ODF spesifikasjonen så les _hele_ OOXML spesifikasjonen som den foreligger. Gjerne prøv å implementer den også, men det vet jeg du ikke har sjangs om å klare, akkurat som alle andre som snakker så varmt om dette fortreffelige mediet.

    Svar
  8. Fredrik E. Nilsen Innleggsforfatter

    Her var det litt av hvert å ta tak i. For det første: Jeg er klar over at mange av ankepunktene som gjelder ODF også gjelder OOXML. Poenget var å vise at ikke alt er bra med ODF på den ene siden, og ikke alt er galt med OOXML på den andre siden, slik blant annet Martin Bekkelund forsøker å antyde. Det har jeg også forsøkt å gjøre klart i mine øvrige replikker.

    #Leverandøruavhengighet:

    Jeg vil gjerne se en liste over de mer enn 10 mer eller mindre fullverdige implementasjonene av ODF som ikke er basert på OO.org. Jeg har lett og lett men ikke funnet i nærheten så mange. Om du har noen pekere så mottas det med takk.

    Her er en oversikt over noen av de applikasjonene som i større eller mindre grad støtter OOXML:

    http://www.openxmlcommunity.org/applications.aspx

    Jeg har ikke sjekket alle disse men det er ikke tvil om at din påstand om at «ingen har klart å implementere noe som klarer å lese et Word-dokument» er ganske langt fra virkeligheten. Det samme gjelder påstanden om at det er «absolutt null leverandøruavhengighet med OOXXML».

    Nå var jo dessuten poenget mitt å bekrefte at det faktisk var en viss leverandøruavhengighet ved å bruke ODF.

    #Sikkerhet mot uønskede endringer:

    Jeg er selvsagt klar over at OSP-en til Microsoft er omstridt. Jeg er ingen jurist og flere jurister har tolket den i alle retninger. Poenget var å få fram at man ikke har noen garanti mot uønskede endringer selv om man velger ODF, til tross for at det er det Martin Bekkelund hevder implisitt. Det viser Sun sin IPR-statement.

    #Mer robuste standarder:

    Hvor dårlig skrevet OOXML-spresifikasjonen er skrevet når det gjelder sikkerhet overlater jeg til andre å vurdere. Det er imidlertid ikke tvil om at OOXML har blitt gjenstand for rimelig omfattende vurderinger siden den ble lagt frem. Det har vært nok av de som har gjort alt de kan for å finne feil og mangler i spesifikasjonen så sjansen for at det er noen uoppdagede grove feil er forsvinnende liten IMO.

    Dessuten: Poenget var igjen å gi et tilsvar til Martin Bekkelunds implisitte påstand om at det ikke var noen fare for virus når det gjaldt ODF. Det er selvsagt bare tøv.

    #Ingen kostnader:

    Jeg skrev tydelig at det handlet om implementasjon av standarden, ikke bruken av programvare. Jeg har ikke hevdet at Office er gratis, kun at det ikke er noen kostnader forbundet med å implementere OOXML.

    #Interoperabilitet:

    Igjen: Martin Bekkelund fremhever at bruken av ODF sikrer interoperabilitet. Jeg har vist til at det ikke er uproblematisk. Jeg har ikke hevdet at det er uproblematisk heller i forhold til OOXML. Selvsagt er ikke interoperabilitet uproblematisk annet enn i helt enkle situasjoner.

    #Økt konkurranse:

    Ut fra det jeg har funnet er ikke konkurransen når det gjelder ODF-implementasjoner all verden. Har du linker som viser noe annet så post dem gjerne. Når det gjelder Microsoft Office så er det vel rimelig trygt å anta at konkurransen ihvertfall ikke blir mindre når de velger å bruk et åpent format som OOXML.

    #Gjenbruk:

    Jeg har ikke hevdet at det i seg selv er positivt at OOXML ikke gjenbruker standarder som eksisterer. Det jeg har sagt noe om er at ODF ikke er uproblematisk når det gjelder gjenbruk av standarder.

    Forøvrig: Hvis man sammenlikner SVG og DrawingML vil man se at forskjellene er svær store og SVG ikke på noen måte gir samme muligheter som DrawingML gjør. Her er en gjennomgang:

    http://openxmldeveloper.org/articles/2683.aspx

    Når det gjelder din sluttkommentar:

    Mitt poeng var igjen ikke å sammenlikne ODF og OOXML og se hvem som kommer best ut. Det er det nok av folk som har gjort før. Jeg har kun forsøkt å påvise at ODF ikke gir alle de fortrinnene Martin Bekkelund hevder.

    Jeg har heller ikke lagt skjul på at jeg er positiv til at OOXML skal bli godkjent som standard i ISO. Jeg mener at OOXML ikke er «verre enn verst» og at ODF ikke er «bedre enn best». Hvis du klarer å tolke det som at jeg mener at OOXML er det beste som har skjedd i verden så skal du få lov til det. Det betyr selvsagt ikke at jeg mener det.

    Jeg har skrevet det i en del andre sammenhenger og får gjenta det her: Microsoft argumenterer for at ODF ikke dekket deres behov og motstanderne av OOXML argumenterer for at Microsoft kun er interessert i å lage et format de selv har kontroll på og ønsker å hindre konkurransen. For min del tror jeg vel sannheten ligger et eller annet sted midt i mellom og at vi over tid vil se en harmonering mellom de to formatene og applikasjonene som produserer dem.

    Begge formatene er legitime i forhold til scope og innhold etter mitt syn og jeg har også flere ganger understreket at jeg ikke er noen motstander av ODF på noen som helst måte.

    Svar
  9. Brynjard Øvergård

    Med andre ord prøver du bare å rakke ned på ODF for å få OOXML til å stå i et bedre lys (og som du selv sier er det ikke en helt god praksis ifølge det du har lært i markedsføring).

    #Leverandøruavhengighet
    Ser de lister opp et utall med applikasjoner på openxdeveloper.org, selv om de aller fleste bare har minimal støte for feks uthenting av tekstinnhold i en OOXML fil. Prøvde selv å finne tak i et lib for å lese OOXML for ca 6 mnd siden og da var det rimelig håpløst å finne tak i noe som fikk dokumentene til å ligne Word sin tolkning, så enten har de implementert i høygir eller så begynner jeg å miste grepet om det jeg holder på med.
    Nå er jo strengt tatt ikke den websiden det mest upartiske siden jeg har vært borti heller, så det _kan_ jo hende de overdriver litt.

    Når det gjelder ODF, vel.. titt innom wikipedia, de lister opp 20-30 apper, de fleste open source og de fleste med sin egen implementasjon. ODF er ikke så fantastisk komplekst, og når man har moduler som støtter de andre standardene er det ikke så altfor mye arbeid heller (hvilket er grunnen til at standarder er en god ide, se mer nedenfor).

    #Sikkerhet mot uønskede endringer:
    Siden du kritiserer ODF fordi du ønsker å promotere OOXML tolker jeg derfor også utsagnene dine deretter. Implementasjoner av OOXML blir nødvendigvis langt mer kompleks enn ODF siden den innfører så mange nye understandarder, og siden dette er en helt ny (relativt sett) standard som har en fantastisk komplisert dokumentasjon (mer omfattende en de aller aller fleste ISO standarder, ny rekord kanskje?) er det benka nødt til å bli et utall med sikkerhetshull.

    At det finnes feil i ODF implementasjoner gir bare en vag pekepinn på hva vi kan forvente oss med OOXML implementasjoner etterhvert som de kommer ut av beta og begynner å bli brukt.

    #Sikkerhet mot uønskede endringer:
    Enig, Sun (m fl.) har en brekkstang som de kan bruke om de absolutt vil (eller tørr). MS har implisit sagt de ikke kommer til å saksøke noen over det som står i specene (siden ECMA krever det)(dette gjelder forsåvidt ODF også), men de har ikke nevnt hva som kommer til å skjer når man implementerer ting som _ikke_ står i specen men som er påkrevd for at det skal fungere (specen krever implisit endel ekstrafunksjonalitet som er utelatt fordi det regnes som en del av systemet (les Windows)).

    #Ingen kostnader:
    Når ble det gratis å hyre 10-12 utvikler i 6 mnd for å imlpementere en spec på 6000 sider?! Problemet er at det ikke finnes noen gode komplette OOXML LGPL (el.) implementasjoner, så hvis man skal bruke det må man per dags dato gjøre en stor jobb selv, og det er alt annet en billig. Med ODF er det bare klipp og lim i forhold.

    #Interoperabilitet:
    Igjen så ser jeg dette i sammenheng med at du ønsker å promotere OOXML. At man innfører en ny overlappende standard (eller mer korrekt: et helt lass siden OOXML inneholder flere understandarder) kommer ikke til å gjøre problemet med interoperabilitet bedre, tvertimot. Grunnen til at ISO har en policy om å bare ha en spec innefor hvert område er nettopp derfor!

    #Økt konkurranse:
    OOXML er per i dag ECMA, og så «åpent» som MS gidder å gjøre det. At det blir ISO sertifisert kommer ikke til å gjøre noe positivt for programvare som ønsker å konkurere mot MS Office, de har allerede tilgang på det de trenger for å implementere OOXML. At det blir en ISO standard gagner bare MS, og siden de effektivt har monopol på Office vil ikke det akkurat gjøre situasjonen noe bedre mht konkuranse. Hverken Sun eller IBM som «tjener» på at ODF blir den eneste ISO standarden har begge mikroskopiske andeler (i forhold til Office). MS kan essuten fort snu om på denne fordelen med å inkludere en bedre ODF støtte i Office (som egentlig er det alle vil, hvorfor gjøre det så sabla vanskelig?!?).

    #Gjenbruk:
    MS har valgt å lage sine egne problemer og løse dem ved å danne seg en ny løsning ut fra deres eget ståsted. Rapporten som er lagt ved er gjennomsyret av kraftig bias fra utviklere som ikke syntes SVG gjør ting på deres måte. Jeg har en god del erfaring fra utvikling i SVG og de fleste eksemplene på ting som «ikke kan løses» i SVG er direkte feil! Det viser bare at MS ikke har vært villig til å gjøre en innsats til å bruke eksisterende standarder i det hele tatt og bare definert sin måte som den rette måten etterhvert som de har lagd Office. De har hatt mye mulighet til å påvirke både SVG, MathML og ODF men de har ikke vært villig til å inngå noen form for kompromi.
    Hvis OOXML blir ratifisert må dermiot alle andre tilpasse seg MS sin «nye» måte å se verden på.

    DrawingML er et godt eksempe på at MS ikke gidder, og at de prøver å snikinnføre en standard som ISO aldri ville godtatt som egen standard fordi den ville vært i direkte konflikt med SVG. Dette gjelder også flere av de andre understandardene i OOXML og gjør ikke akkurat helhetsinntrykket noe bedre.

    —-

    Det jeg skal si meg enig i er at ODF 1.0 slik standarden er i dag er ikke tilfredstillende for interoperabilitet mellom de ulike kontorapplikasjonenen. Den har en god del mangler og er hovedsaklig for enkel. Årsaken til dette er i stor grad av MS ikke har villet gi noen input på hva de ønsker, og at mange andre har kommet inn sent i prosessen (de aller fleste hang seg på først når ODF 1.0 ble ratifisert). MS fikk pluttselig veldig bråhast når de så hva som skjedde med ODF (at den ble en ISO standard), og istedenfor å gi nyttig input på hva de trengte for å få alle opsjonene til Office til å funke med ODF gikk de sin egen vei og begynte heller en kjapp prosess med å få godkjent sitt eksisterende format som en standard.

    At ODF 1.0 ikke er tilstrekkelig er en fantastisk dårlig unskyldning for at MS skal få ratifisert Office som en standard (OOXML er så nært bundet opp mot hvordan Office implementerer ting at det i praksis ikke kan skilles fra hverandre), og dette er _ikke_ et forsøk fra MS sin side å være grei og «sammarbeide» med alle andre. I praksis er det MS som bestemmer hvor skapet skal stå (de har tilogmed formulert det i lovtekst som ISO må godta mot alle tidligere praksiser!) og en halv verden sier ja takk gjerne og bøyer seg over for å ta en i toern.

    OOXML ar ingenting som en ISO standard å gjøre, MS får værsågod gjøre litt innsats for å tilpasse seg de eksisterende standarder som eksistere som alle andre som skal utvikler åpne programmer istedenfor å ta en spansk en fordi de har så mye penger og makt.

    —-

    Det som sjokkerer meg støtt og stadig er hvordan opplyste mennesker (greit nok, ikke alle her som er særlig stø på programmering og lesing av lange dokumenter) kan være så heftige tilhengere av noe de ikke forstår kaka av. Du har for eksempel ganske tydelig veldig lite peil på implementasjon av programvare (ok, kanskje på et overfladisk nivå, men jeg ville sparket fyren som skrev under på vitnemålet ditt isåfall), og har også tydeligvis ikke lest heller lite av hverken ODF sin spesifikasjon eller OOXML. I tillegg har du heller ikke satt det særlig godt inn i hvordan standardorganisasjonen ECMA eller ISO fungerer, og tar kommentarer fra diverse bloggere for god fisk. Og her driver du med din egne lille kampanje for å fremheve OOXML, hva er det som er drivkraften til sånne folk som deg?!

    Jeg har absolutt ingen formeninger om at jeg så mye som kommer til å klarer å rikke på ditt standpunkt om OOXML, uansett hva jeg enn måtte finne på å si, så egentlig så er dette bare for å forsøke å holde diskusjonen litegrann nyansert.

    Svar
  10. Fredrik E. Nilsen Innleggsforfatter

    Brynjard skrev:

    Med andre ord prøver du bare å rakke ned på ODF for å få OOXML til å stå i et bedre lys (og som du selv sier er det ikke en helt god praksis ifølge det du har lært i markedsføring).

    Det er igjen din tolkning og har ikke noe med virkeligheten å gjøre. Igjen: jeg har forsøkt å påpeke at ikke ODF har alle de fortrinnene Martin Bekkelund hevder at det har. Du bygger din argumentasjon på at jeg er mot ODF, hvilket jeg gjentatte ganger har understreket at jeg ikke er. Det virker som du vil få frem en enten/eller-argumentasjon og det er ikke det jeg forsøker.

    #Leverandøruavhengighet:

    På wikipedia står følgende:

    Currently, there are several derived and/or proprietary works based on OOo, with some of them being:

    Sun Microsystem’s StarOffice, with various complementary add-ons.
    IBM’s Lotus Symphony, with a new interface written in Eclipse (based on OO.o 1.x).
    OpenOffice.org Novell edition, integrated with Evolution and with a OOXML filter.
    Beijing Redflag Chinese 2000’s RedOffice, fully localized in Chinese characters.
    Planamesa’s NeoOffice for Mac OS X with Aqua support via Java.

    Dette er langt fra 10 og de fleste er basert på OO.org. Har du noen linker som viser til mer enn 10 mer eller mindre fullverdige implementasjoner av ODF som ikke er basert på OO.org, slik du hevdet i forrige innlegg?

    Når det gjelder listen på Openxmlcommunity så har jeg ikke noen grunn til å tro at det som står der ikke stemmer. Har du?

    #Mer robuste standarder (som jeg antar du mente):

    Jeg har ingen tro på at OOXML er perfekt og uten sikkerhetsproblemer, ei heller at applikasjonene vil være det. Men det var igjen ikke poenget mitt: Martin Bekkelund fremhever det som en fordel med ODF at det implisitt er en mer robust standard og ikke er utsatt for problemer med virus. Det er fortsatt feil. Når det gjelder din tro på at OOXML (og applikasjonene) vil være så mye verre på grunn av spesifikasjonens størrelse og kompleksitet så vil bare tiden vise det. Jeg antar hverken det ene eller andre her.

    #Sikkerhet mot uønskede endringer:

    MS har implisit sagt de ikke kommer til å saksøke noen over det som står i specene (siden ECMA krever det)(dette gjelder forsåvidt ODF også), men de har ikke nevnt hva som kommer til å skjer når man implementerer ting som _ikke_ står i specen men som er påkrevd for at det skal fungere (specen krever implisit endel ekstrafunksjonalitet som er utelatt fordi det regnes som en del av systemet (les Windows)).

    Hvilken ekstrafunksjonalitet er det du tenker på da?

    #Ingen kostnader:

    Vil du misforstå så klarer du det jo. Din argumentasjon blir for meg like meningsløs som å si at Ubuntu koster penger fordi du må kjøpe en PC for å bruke det. For å ta det med te-skje: Du må ikke betale penger til Microsoft eller noen andre for å implementere OOXML, ei heller til Sun eller noen andre for å implementere ODF.

    #Interoperabilitet:

    Og igjen så svarer du på noe helt annet enn det som var mitt poeng. ODF sikrer ikke interoprabilitet, like lite som OOXML sikrer interoperabilitet. Formatene gjør det mulig å arbeide mot større interoperabilitet men det er ingen garanti, selv ikke for ODF. Martin Bekkelund fremhever nettopp dette som et fortrinn med ODF men som Thomas Zander, sjefsutvikler i KDE sier i mailinglista til Oasis:

    One thing I have always dreamed to be possible is that when I write a doc in KOffice I can then open it in OOo to use that one feature that’s useful to me and then save it and continue in KOffice without loosing lots of data.

    Its still a dream, of course. Most features are lost on opening and saving it in OOo, but its a nice goal.

    #Økt konkurranse:

    Sun og IBM har mye å tjene på at ODF blir den eneste standarden. Myndigheter verden over har sagt de vil støtte ODF siden det er en åpen standard og dette tjener Sun og IBM på. Markedsmulighetene deres vil øke betydelig om ikke OOXML blir godkjent i ISO. Norske myndigheter har jo for eksempel satt OOXML på vent. Selv om de ikke eksplisitt har sagt at ISO-godkjenning vil avgjøre er det vel liten tvil om at det vil veie tungt.

    Og for å gjenta det jeg skrev i forrige replikk: Når det gjelder Microsoft Office så er det vel rimelig trygt å anta at konkurransen ihvertfall ikke blir mindre når de velger å bruk et åpent format som OOXML.

    #Gjenbruk:

    Angående SVG og de mulighetene som er der kjenner jeg ikke detaljene godt nok. Hvilke påstander i rapporten er direkte feil?

    Når det gjelder DrawingML så finner jeg dine påstander noe besynderlige. Under avstemmingen i ISO i september var det flere NB-er, deriblant den norske, som foreslo at DrawingML burde foreslås som en egen standard i ISO:

    DrawingML has general applicability as an XML vocabulary for vector graphics. It should therefore be a standard in its own right that can be referenced in isolation by other ISO standards, such as ISO 26300.

    Ecma finner forslaget interessant og foreslår at det blir arbeidet videre med i forbindelse med vedlikehold av OOXML.

    Når det gjelder forholdet mellom Microsoft, Oasis og Sun under oppstarten og utviklingen av ODF har jeg kommentert det i tidligere innlegg og tar derfor ikke den runden en gang til her.

    Din sluttkommentar vel preget av at du har et bestemt syn og at alle som ikke deler det synet er «unyanserte» og «har veldig lite peil». Jeg synes vel ikke dine kommentarer hittil bærer preg av at du heller er veldig nyansert eller har så mye «peil», og jeg tar meg ikke veldig nær av dine sleivspark. At du tyr til den typen språkbruk viser meg bare at du har lite saklig å argumentere med.

    For meg er det ikke nødvendigvis nyansert å være for det ene og mot det andre. Nyansert er å se både de positive og de negative sidene ved både ODF og OOXML. Det er nok av bloggere som kun ser det negative med OOXML og kun det positive med ODF. Du har kommet feil hvis du tror jeg er med på en slik svart/hvitt-tankegang.

    Svar
  11. Einar Stavleik

    Nå har jeg fulgt debatten her videre og jeg må bare spørre rett ut:

    Fredrik, jeg vet ikke hvem du er annet enn at jeg har lest et par ulike bloggposter du har skrevet om OOXML og noen innlegg hos Bekkelund, men si meg – og det er fint om du svarer ærlig – du har vel tilfeldigvis ikke blitt innleid for et lite oppdrag av Microsoft eller et mellomledd for dem, kanskje for å promotere OOXML, litt sånn IT-konsulenten Rana har? Eller har du kanskje betalt jobb i et firma som har økonomisk interesse i promotering av Microsofts teknologier?

    Jeg synes det er vrient å forstå hvordan en antatt uavhengig person med et visst innblikk i debatten klarer å få seg til å innta de synspunktene du stadig ytrer — uten at det ligger en slik forklaring bak.

    Om du mottar honorar i noen form, så er det fint om du også, i likhet med selvesten Rana, er fullstendig åpen om det.

    Selv har jeg ingen økonomisk motivasjon, min interesse for saken går kun på genuin, idealisme da jeg gjerne skulle sett at Microsoft Office med sine hårete (pga bakoverkompatibilitetstråder til gamle da’r) har godt av en endring, samt mer konkurranse i markedet (og at folk slutter å følge de facto-standarder, men lærer å sette pris på viktigheten med ekte åpne standarder).

    Svar
  12. Fredrik E. Nilsen Innleggsforfatter

    Jeg har vel gjort det klart ved et par andre anledninger men kan godt gjenta det her:

    Jeg arbeider som frittstående IT-konsulent og hovedtyngden av mine oppdrag er innen opplæring og bruk av programvare fra Microsoft. Jeg tilbyr de samme tjenestene også for open source-alternativer som for eksempel OpenOffice, men etterspørselen er (foreløpig) forsvinnende liten. Jeg har ved flere anledninger anbefalt kunder å bytte til open source-alternativer fordi jeg har ment det har vært det beste for dem i deres situasjon.

    Jeg mottar ikke, og har aldri mottatt, et eneste øre fra Microsoft, hverken direkte eller indirekte, og betaler alle mine lisenser selv.

    Min interesse for dette går for det meste på det tekniske (som jeg ikke kan nok om ennå men lærer noe om stadig vekk) men også på den ensidigheten som jeg synes preger debatten, både i Norge og ellers. Jeg mener Microsoft har noen helt legitime argumenter, samtidig som jeg selvsagt er klar over at de først og fremst vil drive butikk. IBM og Sun har også sine legitime argumenter men folk ser ut til å glemme at også de først og fremst vil drive butikk. Det er det vel jeg ønsker å sette søkelyset på.

    Og: jeg synes jo det har kommet en del signaler fra Microsoft allerede som er positive. Det er lang vei igjen men jeg synes det er tegn til lys i tunnellen. 🙂

    PS. Godt med et innlegg fra en som ikke leser alt som en nesegrus beundring for alt hva Microsoft foretar seg!

    Svar
  13. Tilbaketråkk: Martin Bekkelund

  14. Brynjard Øvergård

    Vel, med mindre denne bloggen ikke er en del av virkeligheten vil jeg si at du ganske tydelig er en sterk tilhenger av OOXML, og at basis for at du skriver denne artikkelen er fordi du ønsker å sette ODF i et dårligere lys ved å anngripe argumentene som brukes for å fremheve dette formatet. Du gjør dette ved å angripe en av blogginleggene som er skrevet av Martin Bekkelund. Jeg kommenterer i alle fall ut fra dette, og om du velger å ignorere det er opp til deg (at jeg i det hele tatt må spesifisere dette er jo ganske usaklig, men men).

    Tilbake til saken:

    #Leverandøruavhengighet:
    Vel, hvis du ser litt lengre ned på siden finer du en link til en side som lister opp noen programmer som støtter ODF native (dvs uten eksterne biblioteker):
    *AbiWord
    *Adobe Buzzword (online editor)
    *Google Docs
    *Ichitaro (japansk editor)
    *KWord
    *Microsoft word (ikke mindre enn 3 forskjellige plugins, et basert på OOo)
    *EditGrid (online excel)
    *Gnumeric (adskillig bedre støtte for ODF enn OOXML)
    *KSpread
    *KPresent
    + en hel drøss med andre ikke fult så komplette implementasjoner. Og hittil har jeg ikke nevnt Open Office selvsagt, siden du mente det nesten bare var de som hadde støtte for ODF.

    Ser man på den tilsvarende listen over OOXML støtte er den litt mer skrinn, det er ca 3 komersielle aktører som har støtte (har ikke teste hvor god, men regner med Office sin støtte er bra 🙂 ), samt endel patchy implementasjoner i Open Source verdenen. Ingen av de gjør en særlig bra jobb dessverre, og de aller fleste bruker en OOXML -> ODF translator basert på XSLT (mao: kan aldri bli særlig bedre en OK). Ser man videre ned på listen ser man også at de har inkludert mange programmer som støtter utskrift av XML ol. (de kan jo teknisk vise OOXML?) samt endel rå teksteditorer og screen scrapere (som henter ut råtekst fra fil) som støttede programmer (flertallet er under denne katagorien faktisk). Hvis du ikke tror meg så sjekk selv. De lyver teknisk sett ikke – de bare forteller ikke hele sannheten.

    #Mer robuste standarder:
    Det er strengt tatt ganske usaklig å diskutere datasikerhet når man diskuterer et dokumentformat, men ok, min (og Martins) tabbe. Et veldokumentert og enklet format er by design mye sikrere enn et mer kompleskt format (gjerne hvis det også inkluderer mange nye elementer). Siden datasikkerhet avhenger av kvaliteten på implementasjonen, og dette i stor grad henger sammen med antall kodelinjer som krevs og hvor god kvalitetsikring man har slår ODF totalt knockout på OOXML. ODF har eksister lengre, er simplere, har velgjennomprøvde implementasjoner og støtter seg i stor grad på andre allerede eksisterende standarder.

    OOXML er den rake motsettningen, ny standard, enorm spec (med mange hull så den må vel utbroderes også etterhvert), og den har blitt skrevet på mindre en 1/3 så lang tid som ODF standarden (OASIS begynte med ODF som smått å desember 2002 og siden det har vært en åpen prosess har alle kunne fulgt med hele veien, OOXML ble droppet i fanget på ECMA og publisert desember 2006). Do the math, 6 ganger så stor spec på 3 ganger så kort tid, med nesten ingen referanser til andre specs, hvorfor tror du det er smått med OOXML impementasjoner?

    #Sikkerhet mot uønskede endringer:
    Krav om støtte for diverse medieformater (DrawXML krever implisit at du har Quicktime libs tilgjengelig). Små detaljer som at deler av specen bare dumper innholdet slik det opprinelig bla lagret i eldre versioner av Word og lar det være opp til programmet å skjønne noe av det (noe som strengt tatt ikke er noe problem siden det ironisk nok finnes flere og bedre bilioteker for å støtte legacy word formater enn OOXML). Det er også endel referanser (selv om MS har prøvd å bli kvitt dem/skjult dem) til Windows sin måte å addressere ekstrakomponenter på (COM/OLE/ActiveX).
    Specen inkludere også endel litt komiske tags ala doitlikekoreanoffice97didthis og slikt. MS har lovd å forbedre på dette, men bare i ordlyd (meningen er det samme, de bare sier det på en litt finere måte).

    DrawXML er også veldig nært knyttet opp mot måten Word liker å formattere dokumenter og inneholder en god del referanser til Word særheter, noe som gjør at folk som ønsker å vise det «korekt» på andre platformer må etterape Office til en stor grad.

    #Ingen kostnader:
    Og igjen (ad nauseum) feiler du totalt å se poenget som i utgangspunktet var formulert som en spøk. Ja selvfølgelig er en åpen standard per definisjon gratis. Problemet er dog at det er teorien, i praksis koster en OOXML implementasjon deg adskillige kostnader siden du må impementere hele røkkla, teste, verifisere og gjerne oppdatere ganske ofte (i hvertfall i en begynnerfase hvis MS skal rette opp alle uklarhetene i specen).
    Med ODF kan du plukke og velge i mangfoldige implementasjoner som alle er godt gjennomtestede og har god support fra en stor community.

    Summa sumarum er kostnadforskjellen ganske stor på de to formatene, og den kommer til å være det ganske lenge også (og situasjonen kommer ikke til å forverre seg for ODF akkurat heller).

    Svar
  15. Brynjard Øvergård

    #Interoperabilitet:
    For å sikre interoperabilitet trenger man:
    a) En konsis og godt definert standard som dekker foretningsområdet og som inneholder nok funksjonalitet til å dekke alle parter (implementasjoner) sine krav (men ikke mere!)
    b) Alle parter som er involvert må samtykkes om å følge standarden og jobbe for å bli kvitt uoverenstemmelser og å utvikler stadarden(e) videre for å dekke ny funksjonalitet

    BEGGE disse forutsettningene må utfylles for at man skal ha noe håp om god interoperabilitet. MS tråkker midt i salaten med å innføre en ny standard, som går på tvers av tidligere definerte standarder og viser lite sammarbeidsvilje til å tilpassse standarden andres krav. OOXML innholder bare funksjonalitet som kommer fra Office, det er omentrent absolut nul og niks innput fra andre leverandører av kontorprogramvare, og MS er den eneste som har mulighet til å endre på specen.

    Hvordan tror du dette kommer til å utvikle seg fremover, tror du virkelig MS kommer til å inkludere feks ting som OOo er avhengig av i OOXML, isåfall hva skulle være motivasjonen deres for å gjøre det (og de er isåfall de eneste som kan gjøre det også siden de har redefinert åpen standard til å være en standard som bare de bestemmer over)? Tror du at noen av de andre leverandørene er interressert i å bruke OOXML til noe annet enn å importere Office filene til andre formater som de har vært med å lage selv og har mulighet til å jobe videre med?

    #Økt konkurranse:
    IBM og Sun har mye å tjene på at ODF blir den eneste ISO standarden ene og alene på grunn av at MS har valgt å ikke støtte ODF. Det er med andre ord MS sitt eget bevisste valg som fører til at andre får en fordel i forhold til dem. ISO sin oppgave er ikke å beskytte leverandører som velger å ikke støtte standarder mot «urettferdig» konkuranse fordi de ikke vil ta i bruk eksisterende standarder.

    Hverken Sun eller IBM kommer dessuten ikke til å ha de helt store inntektene av dette, de har som kjent ingen mye utbredte kontormiljø, og ODF frontes hovedsaklig av OOo som som kjent er gratis. De begge satser hovedsaklig på å støtte standarden i andre sammenhenger (dokumentarkiv, lokale søkemotorer ol.), markeder som MS ikke er inne på i særlig stor grad (selv om de prøver hardt).

    Og hvorfor skulle MS få mer konkuranse om de får ratifisert OOXML som standard? OOXML er vanskelig å implementere og det vil ta lang tid før OOo og andre produkter kan støtte «standarden» like godt som MS, i mellomtiden vil MS ha en stor fordel iogmed at det er de som har definert standarden helt alene, og de kan endre den akkurat som de selv vil uten at noen andre kan komme med nevneverdige invendinger.

    #Gjenbruk
    At du ikke vet hva SVG kan, samtidig som du forsvarer DrawML viser jo bare litt hvor lite du vet 😛
    For å gjre en lang historie kort: DrawML er mer eller mindre et speil av MS sin interne strukturering av tegning av Word dokumenter dumpet til XML. Den bærer ganske tydelige preg av dette, både i struktur, hvordan taggene er definert og hvordan den er oppbyggd. Interne representasjoner passer seg sjelden godt i standarder med mindre du ønsker å gjøre en spesifik implementasjon til en standar. Hvorfor er en lang historie, hvis du vil vite mer har jeg et titals bøker jeg kan anbefale deg å lese først, men den korte forklaringen er at intern representasjon har en tendens til å blande konsepter og gjør det et skikkelig dritjobb for andre å gjøre noe fornuftig med dataene og fremdeles vise dem på samme måten uten å speile den interne representasjonen.
    Så, tilbake til saken. ECMA har vedtatt OOXML og er derme stuck with it, så de må nesten prøve å gjøre det beste av det. En av tingene som vil gjøre vedlikehold av DrawML enklere er å skille det ut som en egen standard (egentlig ganske dumt å ha en ISO standard med så mange komplekse understandarder også, så om de skuel bli en ISO standard er det en god ide å gjøre det samme der). Det er med andre ord ikek fordi DrawML har så fantastisk mye å tilføre verden, men på grunn av at hvis man på død og liv skal ha OOXMl med og må ha DrawML er det mest fornuftig å skille det ut i en egen standard.

    De feilene som jeg refererte til i den «artikkelen» er også nært relatert til dette. DrawML har sin egen måte å se verden på, og ser verden bare i sammehneng av at det er et Word dokument den skal vise, og tilbyr derfor heller lite fleksibilitet som et generelt vektor format. Mange av tingene som de skrev ikek støttes av DrawML er et resultat av dette, de nevner feks at SVG ikke støtter å lage lister «slik MS Word gjør det» og dermed ikek er egnet for dette. Joda, SVG har ikke et tag som sier «render dots like Word», men det er ikke akkurat noen stor utfordring å få dette til. SVG sitt USE tag er veldig anvendelig, og det ville ha kunne støttet nesten samtlige av de scenrarioene de tok for seg støttes i DrawML men ikke i SVG. De kommer feks også med påstander at SVG ikke støtter video og lyd, som støttes i SVG 1.2 og oppover.
    DrawML som vektorformat kunne med andre ord i beste fall vært et lite subsett av det SVG er, med litt HTML innomelom (de blander tekst formatering og grafikk i et format). SVG er et veldig kraftig vektor format, og DrawML er (ut fra det som std i artikkelen, og ut fra det jeg finner om det i spec’en) adskikklig simplere og mindre fleksibelt. Det er sikkert noen som ville brukt det, men hvorfor diversifisere og innføre en ny standard som er dårligere enn den foregående?

    OOXML bærer også tydelige preg av at det ern en hastejobb, den inneholder mange helt uavklarte seksjoner og selvmotsigelser i tillegg til at den innfører et helt hav av nye begreper og understandarder som har veldig lite eller ingenting til felles med andre standarder. De andre standardene som er ratifisert av ISO har i stor grad vært ment på gjennbruk, og normalisering og verifisering av de enkelte detaljene i standarder tar enormt med arbeid og mye tid (PDF er et eksempel, det har tatt mange års arbeid å få denn inn som standard, og specen er mer eller mindre totalt vantett etter mange ittearsjoner). OOXML skiller seg ganske kraftig ut både i mengen spec, mangelen på menge tid som er brukt til å verifisere den, hastighet den skal vedtas med og i mangelen på inflytelse fra 3. part på standarden (omentrent nøyaktig null(som i verdien)).

    ——-

    Gjennomganstema og grunnen til at jeg skrev posten i utganspunktet var at i alle områdene man kunne kritisere ODF (du til tilfeldigvis for deg Martin Bekkelunds kommentarer) så stille OOXML adskillig dårligere enn ODF. Det virker som du bare vil kommentere i forhold til det Martin sier, og det er du i din fulle rett til (det er jo tross alt din blogg), men det hjelper ikke akkurat på at det enda ikke er dukket opp noen særlig troverdig begrunnelse for at OOXML bør innføres som en standard i ISO.

    Du sier at du mener MS har legitime argument for å innføre OOXML som ISO standard, hva er isåfall disse argumentene, og klarer disse argumentene å forsvare OOXML har ihht til ISO sertifisering? Det jeg mener er ensidig er at det er få bloggere som faktisk gidder å se saken fra begge sider, du sier du er interressert i det tekniske aspektet, men viser gang på gang at du har absolutt null peiling på problemstillinger som er veldig relevante for saken. At du jobber som «konsulent» med «hovedtyngde innen opplæring og bruk av programvare fra Microsoft» forteller jo gså sitt om hva slags nivå din tekniske kompetanse ligger på (hvis du hadde hatt en relevant utdannelse og karakterer over stryk ville du ikke hatt den jobben slik jobbmarkedet er i dag).

    -innlegget er redigert-

    Svar
  16. Fredrik E. Nilsen Innleggsforfatter

    Først: Jeg har ikke lagt skjul på at jeg er tilhenger av at OOXML skal bil godkjent som standard i ISO og jeg har argumentert for hvorfor jeg mener det. For å gjenta nok en gang: Poenget med denne artiklen var å stille spørsmål om ODF gir alle de fortrinnene som Martin Bekkelund hevder i sin artikkel. Jeg mener ikke at alt er bra med OOXML og at alt er galt med ODF, jeg mener mye er bra med begge. I sin nåværende form har begge sin berettigelse ut fra det scopet de hadde IMO.

    #Leverandøruavhengighet:

    Flere av de du lister opp er ikke det jeg vil kalle fullverdige implementasjoner. Med fullverdige implementasjoner mener jeg applikasjoner som støtter alt det vesentligste av funksjonalitet og som har ODF som standard lagringsformat. Det er derfor jeg også tidligere har skrevet at det per dags dato kun er en fullverdig implementasjon av OOXML (MS Office 2007). Google Docs støtter for eksempel kun en svært elementær del av funksjonaliteten i ODF og er langt fra en fullverdig implementasjon.

    Når det gjelder mindre fullverdige implementasjoner av OOXML viser jeg til oversikten her:

    http://www.openxmlcommunity.org/applications.aspx

    Siden du hevder at «ingen av disse gjør en særlig bra jobb dessverre» regner jeg med at du har testet ut de forskjellige og har en eller annen form for dokumentasjon over hvor de gjør en dårlig jobb (utover det Martin Bekkelund har vist til når det gjelder NeoOffice).

    Jeg har ikke testet mer enn et par stykker som har fungert greit men ikke optimalt.

    #Mer robuste standarder:

    Du feiler i utgangspunktet for diskusjonen. Martin hevder implisitt av makrovirus ikke er noe problem om man bruker ODF. Det er selvsagt bare tøv og det er det jeg har vist til.

    Det er som du sier mange faktorer som avgjør og jeg har ikke på noen måte hevdet at OOXML er bedre enn ODF på dette området.

    Når det gjelder tidsbruk så arbeidet MS med XML-baserte formater allerede i forbindelse med Office 2000. Når Office 2003 kom ble de XML-baserte formatene publisert og gjort tilgjengelige. Disse formatene var utgangspunkt for OOXML og OOXML ble overlatt til ECMA i november 2005.

    #Sikkerhet mot uønskede endringer:

    Brynjard skrev:

    Krav om støtte for diverse medieformater (DrawXML krever implisit at du har Quicktime libs tilgjengelig).

    Dette har jeg ikke funnet noe informasjon om noe sted. Har du en link?

    Små detaljer som at deler av specen bare dumper innholdet slik det opprinelig bla lagret i eldre versioner av Word og lar det være opp til programmet å skjønne noe av det (noe som strengt tatt ikke er noe problem siden det ironisk nok finnes flere og bedre bilioteker for å støtte legacy word formater enn OOXML).

    Hva tenker du på da, helt konkret?

    Det er også endel referanser (selv om MS har prøvd å bli kvitt dem/skjult dem) til Windows sin måte å addressere ekstrakomponenter på (COM/OLE/ActiveX).

    Igjen, vær konkret.

    Specen inkludere også endel litt komiske tags ala doitlikekoreanoffice97didthis og slikt. MS har lovd å forbedre på dette, men bare i ordlyd (meningen er det samme, de bare sier det på en litt finere måte).

    Dette har jeg kommentert mange ganger tidligere men for ordens skyld:

    Disse delene av spesifikasjonen er med for at applikasjonene skal kunne tolke formateringer fra de tidligere binære formatene. Det er IMO bare en fordel. De er direkte spesifisert i proposed disposition fra ECMA og er også plassert i et anneks for utgåtte funksjoner. De skal ikke brukes for nye dokumenter eller gamle dokumenter som lagres i nytt format. Funksjonaliteten er kun nødvendig å implementere om du lager en applikasjon som skal kunne åpne og konvertere dokumenter i de gamle binære formatene.

    #Ingen kostnader:

    Igjen bommer du på utgangspunktet for diskusjonen. Martin Bekkelund fremhever at det er et fortrinn at det ikke er noen kostnader ved å implementere åpne formater som for eksempel ODF. Med din argumentasjon er det helt sikkert rimeligere å implementere ODF enn OOXML men det er fortsatt kostnader forbundet med det.

    #Interoperabilitet:

    Jeg er fullstendig klar over hva som kreves for å sikre interoperabilitet, men jeg lurer jo på om du i det hele tatt har lest det jeg har skrevet. Jeg har ikke noe sted hevdet at interoperabilitet er uproblematisk med OOXML, jeg har kun hevdet at det heller ikke er uproblematisk med ODF. Det har jeg blant annet vist til i tidligere innlegg her og i sitatet fra Oasis sin mailingliste.

    #Økt konkurranse:

    Brynjard skrev:

    Hverken Sun eller IBM som “tjener” på at ODF blir den eneste ISO standarden (…)

    IBM og Sun har mye å tjene på at ODF blir den eneste ISO standarden ene og alene på grunn av at MS har valgt å ikke støtte ODF.

    Hva mener du egentlig? Har de noe å tjene på det eller har de det ikke?

    Jeg får også bare gjenta det jeg har sagt nå mange ganger: ved å åpne sine dokumentformater er sannsynligheten større for at Microsoft får reell konkurranse til sine Office-programmer.

    #Gjenbruk:

    Brynjard skrev:

    DrawML er mer eller mindre et speil av MS sin interne strukturering av tegning av Word dokumenter dumpet til XML. Den bærer ganske tydelige preg av dette, både i struktur, hvordan taggene er definert og hvordan den er oppbyggd.

    snip…

    DrawML har sin egen måte å se verden på, og ser verden bare i sammehneng av at det er et Word dokument den skal vise, og tilbyr derfor heller lite fleksibilitet som et generelt vektor format. Mange av tingene som de skrev ikek støttes av DrawML er et resultat av dette, de nevner feks at SVG ikke støtter å lage lister “slik MS Word gjør det” og dermed ikek er egnet for dette.

    Ut fra scopet som var for OOXML vil jeg jo si at det ikke er urimelig at DrawML er utformet som det er.

    Brynjard skrev:

    De kommer feks også med påstander at SVG ikke støtter video og lyd, som støttes i SVG 1.2 og oppover.

    Nei, de hevder ikke at SVG ikke støtter video og lyd. Her er det som står i analysen:

    DrawingML gives the users an option to embed media files within Office documents. However, in SVG users can only link to such media files.

    Når det gjelder NB-enes begrunnelser for å anbefale at DrawML burde bli en egen standard så antar jeg at du har noe dokumentasjon for dine påstander.

    Og igjen må jeg jo bare få understreke: Jeg har ikke hevdet at DrawML er aldeles fortreffelig og løsningen på alt. Jeg har kun påpekt at ODF ikke er i nærheten av å implementere SVG i det hele tatt. ODF bruker et eget internt tegneformat som ikke er kompatibelt med SVG.

    Brynjard skrev:

    Du sier at du mener MS har legitime argument for å innføre OOXML som ISO standard, hva er isåfall disse argumentene?

    At ODF ikke dekker på langt nær den funksjonaliteten som er nødvendig for Microsoft sine Office-formater. At Sun har patentrettigheter til ODF som kan begrense utviklingen av formatet i retninger Sun ikke ønsker. At ODF ikke kan ivareta struktur, formatering og innhold fra eksisterende dokumenter i Microsoft sine binære formater.

    Alle disse argumentene er legitime. I tillegg har selvsagt MS forretningsmessige argumenter, det har jeg aldri lagt noe skjul på.

    Brynjard skrev:

    At du jobber som “konsulent” med “hovedtyngde innen opplæring og bruk av programvare fra Microsoft” forteller jo gså sitt om hva slags nivå din tekniske kompetanse ligger på (hvis du hadde hatt en relevant utdannelse og karakterer over stryk ville du ikke hatt den jobben slik jobbmarkedet er i dag).

    For det første: Du har ikke vist noen enorm teknisk kompetanse her så jeg velger å ikke ta meg veldig nær av dine påstander. For det andre: Jeg trives utmerket godt med den jobben jeg har og har ikke noe som helst ønske om å bytte til å gjøre noe annet. Hva er det du vil fram til?

    Brynjard skrev:

    Nesegrus beundring for MS eller ikke, du jobber med desktop programmer og primært (bare?) på Windows – hvis det eneste du vet om er MS sine produkter (noe som lyser igjennom ganske sterkt) så har du jo ikke akkurat noen grunn til å tro at det finnes noe annet brukbart der ute?

    Jeg jobber i hovedsak på Windows-platform fordi det er det mine kunder etterspør. Som sagt før tilbyr jeg de samme tjenestene også for andre alternativer men etterspørselen er forsvinnende liten, bortsett fra noen kurs på Office for Mac ved enkelte anledninger. Jeg bruker også flere Open Source-alternativer på mine egne systemer og har også anbefalt det for flere av mine kunder de gangene jeg har ment det har vært riktig.

    Når det gjelder dine kommentarer om hva som lyser igjennom og hva du tror ting virker som så sier det vel mer om deg selv. Den typen personangrep du driver med kan du spare deg og jeg har redigert bort de avsnittene som kun inneholder utskjelling. Neste gang ryker hele kommentaren om du ikke kan beherske deg.

    Svar
  17. Brynjard Øvergård

    Gah, du er jo helt håpløs å diskutere med, først svarer du ikke på direkte spørsmål, og når du først gjør det svarer du uten å svare på det faktisk spørsmålet men istedenfor stille nye spørsmål. Jeg blir feilsitert, du sjekker ikke opp bakgrunnen for min argumentasjon (det er ikke plass her for å gjengi hele spesifikasjoner), og som om ikke det er nok så redigerer du bort ting fra kommentarer som du ikke synes passer!!!

    Det første poenget mitt, som enda står ubesvart og uforsvart, er at du ved å kritisere argumenter for ODF bare gjør det værre for OOXML siden disse «svakhetene» er mye større med OOXML enn ODF.

    Så, og langt viktigere, det andre poenget mitt, som du har valgt å klippe (delvis) bort fra min kommentar er hvorvidt det er noe hold i din synsing om denne saken. Du referer stort sett konsekvent ikke til eksterne kilder, og de gangene du har gjort det har du ikek sjekekt dem på forhånd og endt opp med at de bare har bevisst mitt poeng (og ikke det du ville frem til).

    Så tilbake til det første poenget:
    #Leverandøruavhengighet:
    Riktig, omentrent alle (bortsett fra Office) på den lista er delvise implementasjoner. De aller fleste bruker et XLST filter for å konvertere fra OOXML til ODF for så å bruke den innebygde støtten for ODF (ganske ironisk siden et av hovedpoengene til MS mot ODF er at det ikke gir bra nok støtte for OOXML). Som «alle» vet kan ikke en slik konvertering ikke bli perfekt (ikke pga ODF vel og merke) og det er _dette_ jeg kommenterer som at “ingen av disse gjør en særlig bra jobb dessverre”.

    Du trenger ikke lese så veldig mye på hvert program for å få vite hva slags metode de bruker for å lese inn OOXML, og ut fra dette er det ganske lett å se hva slags nivå de støtter OOXML.

    #Mer robuste standarder:
    Du forstod tydeligvis ikke implikasjonene av det jeg sa, men ok. Makrovirus er nært knyttet til kompleksisteten på implementasjonen (faktisk ganske nøyaktig direkte knyttet til kompleksiteten), og jeg prøvde å påpeke at OOXML implementasjoner nødvendigvis blir mye mer komplekse.

    Tidsbruk: Hvor mange av de eksterne partene som i dag «må» implementere OOXM hadde tilgang til spec’en før den ble publisert som en ECMA standard? (svar: ingen, med unntak av MS da seff). Hvor mange hadde tilgang til ODF? (svar: alle som ville, men kunne tilogmed påvirke formatet og få inkludert ting man trengte)

    #Sikkerhet mot uønskede endringer:
    DrawML bruker QuickTime format på video og lyd (les i spec’en).

    Spec’en inneholder mulighet for at det orgniale word dokumentet kan inkluderes. Helt greit egentlig, men dette blir i praksis en feature som bare Office kan støtte på noe fornuftig vis. Det stilles eller ikkr krav til forholdet mellom det gammle dokumentet og det «nyformatterte», så hvis det blir visuelle endringer (som MS mener er problemet med ODF, men som også uungåelig blir et problem med OOXML) vil det _bare_ være Office som kan komme deg til unnnsettning og vise dokumentet slik det originalt skulle se ut (ved å laste inn det orginale dokumentet.

    For mye å nevne, men en god del av spec’en er et speil av VB og C++ interfacer av diverse klasser. Det er endel av klagene (i ISO prosessen) som har nevnt dette mer spesifikt, men det er så mange å gå igjennom at jeg giddr ikke akkurat nuh (hvis det plager nattesøvnen din kan jeg godt hjelpe deg å lete de frem).

    Tag som ineWrapLikeWord6, uiCompat97To2003, autoSpaceLikeWord95 og useWord2002TableStyleRules er ikke på listen over utgåtte funksjoner. At MS ike har giddet å spesifisere nærmere hva dise elementene betyr er bare ren latskap (eller inkompetanse, men det går for det samme) fra deres side og gjør det vanskelig for andre å implementere dette, Hvis ikke MS selv vet hvordan det funker, hvordan skal andre eksterne aktører vite dette!?

    #Ingen kostnader:
    OOXML er et åpent format per definisjon, men det vil ikke være gratis å implementere (i motsettning fra feks ODF), les forrige poster for hvorfor – du forstod tydeligvis ikke hva jeg skrev?
    Åpent format != gratis, LPGL == gratis.

    #Interoperabilitet:
    Tydeligvis ikke. Det virker som du tror interoperabilitet kommer av at man har en detaljert nok spesifikasjon som inneholder alt man trenger å vite for å lese og formattere dette.
    Dette er kort og godt: feil.
    For å få til interoperabilitet må man ha et format som er minste felles multiplum av de ulike programvarepakkene som skal støtte formatet, koblet med innebygget fleksibilitet i formatet for å ta hensyn til de ulike implementasjonenes særegenheter, samt et rammeverk og detaljerte prosedyrer for hvordan disse kan samhandles og tolkes om til et felles språk.
    I OOXML tar man _bare_ hensyn til Office sine særheter, og det vil nesten være teoretisk umulig å støtte dette formatet ved å bruke en anne implementasjon av interne strukturer enn det Office gjør (finnes edel papers som eviser dette, men vet ike om alle forutsetningene er tilstede). Lang historie hvorfor som jeg prøvde å simplifisere i forrige melding, dog mine pedagogiske evner er litt begrensede.

    #Økt konkurranse:
    To forskjellige betydninger av tjene, den i gåseøyne menes med økonomisk, den andre kred.

    Hvorfor vil denne sansynligheten øke? Hvorfor er det sansynlig at alle halveis dårlige OOXML impementasjoner kommer til å gjøre det bedre mot Office sin perfekte imlementasjon om dette blir en ISO standard? Hva vil være forskjellen i forhold til dagens ECMA standard? Dokumentformatet er allerede åpent, hva blir forskjellen for partnere om de må konkurer med MS på hjemmebane (til MS)?

    #Gjenbruk:
    «Ut fra scopet som var for OOXML vil jeg jo si at det ikke er urimelig at DrawML er utformet som det er.»

    For MS nei, for alle andre ja!
    Hvordan (med tanke på at vi i praksis får Office ratifisert som en standard i form av feks DrawML) skal andre ha nytte av dette?

    «Nei, de hevder ikke at SVG ikke støtter video og lyd. Her er det som står i analysen: …»
    SVG linken som de referer til er en URI. Den kan referer til hva som helst, også inline elementer (hvis du skulle være dum nok til å inkludere en raw video i et XML dokument).

    «At ODF ikke dekker på langt nær den funksjonaliteten som er nødvendig for Microsoft sine Office-formater. At Sun har patentrettigheter til ODF som kan begrense utviklingen av formatet i retninger Sun ikke ønsker. At ODF ikke kan ivareta struktur, formatering og innhold fra eksisterende dokumenter i Microsoft sine binære formater.»

    Kan du dokumentere disse påstandene? Jeg har nemlig sett (og brukt) et ganske stort antall applikasjoner som ikke harnevneverdige problemer med å laste inn legacy Word dokumenter og vise disse med mer enn tilstrekkelig nøyaktighet. Også siden de fleste OOXML implementasjonene bruker en OOXML->ODF konverter er det vel en litt døfødt løsning om ikke ODF støtter nok av OOXML til å gjøre en tilstrekkelig god jobb?

    Denne påstanden fra MS virker ikke helt ulig påstanden deres på 90 tallet om at IE var absolutt helt og holdent koplett umulig å avinstallere fra Windows. Det måtte en mangeårig rettsak til med utallige utsettelser med trenering og advokatkverulering i høyeste klasse til før de endelig (etter å ha blitt dømt for monopoli) innrømmer at neida, det var ikke så veldig vanskelig likevel.

    ODF inneholder et minste felles multiplum av funksjonalitet, som det er jobbet hardt for at skal v@ære mulig å kunne bruke til å representere alt som man skulle trenge i et dokumentformat. Det er ikek perfekt, og det vil nok i enkelt tilfeller kreves endel arbeid, men tror du ikke MS med sine ca 79000 ansatte, klarer å gjennomføre noe slikt, noe både Nåvell, IBM, OOo og en rekke andre mindre hobbyaktører mer eller mindre har løst på fritiden.

    Er du virkelig så naiv at du kjøper dette argumentet uten noen særlig mer detaljert begrunnelse?

    Når det gjelder Sun’s patentrettigheter har MS en langt større kvote med patenter hos Sun enn sun har hos MS (de fleste store aktører har en stilltiende avtale om å ikke saksøke hverandre pga patenter fordi de bruker endel av de andres patenter, dette er en ganske vanlig praksis)

    «Alle disse argumentene er legitime. I tillegg har selvsagt MS forretningsmessige argumenter, det har jeg aldri lagt noe skjul på.»

    Alle disse ene argumentet ditt (argumenter mot Sun er et ikke argument, det andre er en variant av det første) er som sagt i min bok ikke særlig valid, og det er ikke på langt nær kraftig nok til å overbevise meg om at MS skal få lov til å bryte med grunnlreglene ISO har satt seg for hva som skal kreves av en standard.

    Svar
  18. Brynjard Øvergård

    Så for poeng nummer 2:

    «For det første: Du har ikke vist noen enorm teknisk kompetanse her så jeg velger å ikke ta meg veldig nær av dine påstander. For det andre: Jeg trives utmerket godt med den jobben jeg har og har ikke noe som helst ønske om å bytte til å gjøre noe annet. Hva er det du vil fram til?»

    Hvis du hadde hatt en utdannelse som hadde fokusert på det teknisk it tør jeg å rimelig bombastisk påstå at du ikke ville jobbet som som “konsulent” med “hovedtyngde innen opplæring og bruk av programvare fra Microsoft”. Man utdanner seg ikke som flymekaniker for å jobbe som purser.

    Jeg kunne godt vist deg CV’en min, har jobbet innen faget i 4-5 år og har 5 års utdannelse. Jeg regner med dog fremdeles som en junior med mye igjen å lærer og grunnen til at jeg tør uttale meg om akkurat denne saken er at jeg har endel praktisk erfaring med implementasjon av legacy excel og word lesing/skriving, samt konertering mellom ulike formater. Har også lage en og annen app i SVG, så jeg liker ikke at folk disser SVG uten å ha noen god og saklig grunn 😛

    Noen særlig god pedagog er jeg tydeligvis heller ikke.

    «Jeg jobber i hovedsak på Windows-platform fordi det er det mine kunder etterspør. Som sagt før tilbyr jeg de samme tjenestene også for andre alternativer men etterspørselen er forsvinnende liten, bortsett fra noen kurs på Office for Mac ved enkelte anledninger. Jeg bruker også flere Open Source-alternativer på mine egne systemer og har også anbefalt det for flere av mine kunder de gangene jeg har ment det har vært riktig.»

    Ville du spurt en Honda forhandler om hvilken Skoda du skulle kjøpt deg? Jobben din er å vite alt som MS sine produkter (siden det er det kundene dine tilfeldigvis etterspør), og det gir deg et ganske kraftig bias. At du ikke har selvinnsikt nok til å skjønne dette er ikke mitt problem.

    «Når det gjelder dine kommentarer om hva som lyser igjennom og hva du tror ting virker som så sier det vel mer om deg selv. Den typen personangrep du driver med kan du spare deg og jeg har redigert bort de avsnittene som kun inneholder utskjelling. Neste gang ryker hele kommentaren om du ikke kan beherske deg.»

    Det vises godt at du har et kraftig bias. Ut fra kommentarene dine vises det også ganske tydelig at du bare har interesse for teknikk og ikke noen formell utdannelse innefor faget (eller det kan du gjerne, men du har isåfall nøyd deg med utdannelsen og har ikke jobbet særlig aktivt med å oppdatere deg på endel ting). Jeg har prøvd å ikke drive med direkte personanngrep, men hvis du oppfatter det som dette er det vel ikke noe jeg kan gjøre med. Det må være lov til å stille kritiske spørsmål en debatants bakgrunn og kunnskapsnivå på et fagområde, spesielt så mye som du «missforstår» argumenter og totalt ignorere kommentarer om arkitektur og implementasjoner som ville fått enhver foreleser til å ha mareritt i flere måneder fremover.

    Jeg stiller kort og godt spørsmål ved om din vage interesse for teknikk er godt nok til å kunne diskutere dette på et såpass detaljert nivå som vi gjør? Vi diskutere detaljer ved implementasjoner som det tar vanlige folk 3-4 år med hardt arbeid for å i det hele tatt se den generelle strukturen på, og ting som dette avfeier du i mange tilfeller som uviktig (eks sammenheng mellom intern struktur og DrawML og interoperabilitet). Ved mange av de andre tingene jeg har nevnt har du ganske tydelig også visst liten forståelse for design og arkitetur, og jeg har i mange tilfeller skrevet feil (ubevisst og bevisst) på helt åpenbare ting feil uten at du har reagert på dette.

    I tillegg består mange av postene dine av kritikk (og denne er basert på det) av andre bloggere som (på papiret) har langt mer fartstid og erfaring på dette området enn deg. Jeg kommenterte også (noe du klipte vekk) at du kaller Rob Weir som «useriøs» og karaktieriserer en rekke kommetarer han har gjort som «på grensen til det latterlige», uten å ta høyde for at du ikke kjenner opptakten til disse kommentarene og uten at du har gjort nevneverdige forsøk på å belyse begge sider i saken. Du prøver med andre ord å gi intrykk av å vite bedre enn folk som har langt bedre meritter enn det du har.

    Jeg står for det jeg mener, og hvis du ikke tåler argumentasjonen som blir brukt vil jeg ha meg frabedt at du redigerer deler av innleggene mine. Enten lar du dem ligge ute i sin helhet, eller så sletter du hele diskusjonstråden og opplyser om dette. Jeg har forståelse for om du ikke vil ha en slik duskusjon på ditt eget forum, men hvis du ikke er villig til la diskusjonen være uhildet av dine egne muligheter til å redigere vekk ting du ikke ønsker å svare for får du heller ta det som en mann og opplyse om dette.

    Svar
  19. Fredrik E. Nilsen Innleggsforfatter

    Brynjard skrev:

    Jeg står for det jeg mener, og hvis du ikke tåler argumentasjonen som blir brukt vil jeg ha meg frabedt at du redigerer deler av innleggene mine. Enten lar du dem ligge ute i sin helhet, eller så sletter du hele diskusjonstråden og opplyser om dette. Jeg har forståelse for om du ikke vil ha en slik duskusjon på ditt eget forum, men hvis du ikke er villig til la diskusjonen være uhildet av dine egne muligheter til å redigere vekk ting du ikke ønsker å svare for får du heller ta det som en mann og opplyse om dette.

    Det er kun en ting jeg sletter eller redigerer her og det er rene utskjellinger som ikke har noe med saken å gjøre. Da velger jeg å fjerne det jeg mener er usaklig utskjelling og la resten stå. Hvis du ikke liker det har to du muligheter: skjerp språkbruken og hold argumentasjonen saklig, eller la være å poste. Jeg har ingenting i mot saklige diskusjoner men dine utskjellingstirader har ikke noe her å gjøre, uansett hvem de er rettet mot.

    Svar
  20. Chava Meadows

    I believe one of your advertisements triggered my web browser to resize, you probably would like to put that in your blacklist. ODF – et Ã¥pent alternativ? Fredrik E. Nilsens Blogg is really a cool name for a blog BTW 😉

    Svar

Legg igjen en kommentar

Fyll inn i feltene under, eller klikk på et ikon for å logge inn:

WordPress.com-logo

Du kommenterer med bruk av din WordPress.com konto. Logg ut / Endre )

Twitter picture

Du kommenterer med bruk av din Twitter konto. Logg ut / Endre )

Facebookbilde

Du kommenterer med bruk av din Facebook konto. Logg ut / Endre )

Google+ photo

Du kommenterer med bruk av din Google+ konto. Logg ut / Endre )

Kobler til %s