Minua ihmetyttää yksi argumentti keskustelussa: OOXML:n vastustajat ovat sitä mieltä, että OOXML:ää ei saa standardisoida koska on olemassa jo samaa tekevä kilpaileva standardi (ODF).

ISO on standardisoinut esimerkiksi vinon pinon ohjelmointikieliä: Fortran, Ada (kolmesti), Basic, C, C++ ja C#. Näillä tehdään samaa asiaa: ohjelmoidaan tietokonetta.

On hämmästyttävää, että esimerkiksi C#:n standardisoinnista ei ole noussut vastaavaa meteliä kuin OOXML:n, vaikka se hyväksyttiin ihan samanlaisessa nopeutetussa menettelyssä ja tuli niin ikään Ecman kautta.

Onko odotettavissa, että C#:n uusien versioiden ISO-standardisoinnista nousee samanlainen poliittinen kiista?

Tähän standardisointikeskusteluun on ehkä myös mielenkiintoista tuoda näkökulmaa Javan standardisoinnista ja avautumisesta. Sun on pitänyt pitkään Javaa omassa kontrollissaan ja saanut aikaiseksi muun muassa kitkeriä kommentteja avoimen lähdekoodin yliprofeetta Stallmanilta (ks. http://www.gnu.org/philosophy/java-trap.html) ja jopa itse Linukselta. Lisäksi Sun on kahdesti vetänyt Javan standisointihakemuksensa pois – sekä ISO:lta, että ECMA:lta.

Tämä paperi kertoo asiasta aika hyvin: http://csdl2.computer.org/comp/proceedings/hicss/2001/0981/05/09815015.pdf

Uutisessa ei muuten kerrottu mitä SFS:n puhenjohtaja kommentoi. Saisiko tästä referaatteja?

Kaikkein järjettömin vaihtoehto olisi kaksi erilaista, yhteensopimatonta standardia.
Se olisi sama kuin ei mitään standardia …ja ohjelmat (tiedostojärjestelmät) eivät olisi tuolloin yhteensopoivia.

Standardin ensimmäinen ja perusolemushan on, että kaikki perkivät sitä noudattamaan ja kaikkien toetteet ovat – tässä tapauksessa – yhteensopivia keskenään.

On toki paljon muitakin standardeja, esim laadullisia ym…

Mitähän siitäkin tulisi, jos 2×42 pattiki-kokojakin olis useampia samoissa seinissä?
…no ileisesti vempula ja/tai irvistelevä seinä – materiaalista riippuen…

ps ohjelmointikielissä standardi ei oo ihan noin tarkka, jos eri kielillä pystytään luomaan yhteensopivia softia, niin mitäs väliä sillä on vaikka olisvatten hiukka eri tavoin tuotettuja.

Silloin kun kyseessä on standardi, tulisi sen 100% noudattamisen olevan jokaiselle osapuolelle mahdollista. ooxml on standardi jonka vain Microsoft pystyy toteuttamaan täydellisesti.
http://holloway.co.nz/can-other-vendors-implement-ooxml.html

ooxml standardi jättää asioita kertomatta(taaksepäin yhteensopivuus), sisältää toimintoja, jotka ovat ristiriidassa muiden ISO-standardien kanssa, ei ole edes validia XML:llää ja kaikenlisäksi sisältää jotain naurettavia päivämääräbugeja.

Kyllä siitä voi ISO standardi tulla, muttei nopeutetulla aikataululla. Sitten kun virheet on korjattu.

Pohjimmiltaan kysymys on siitä, että saadaan tiedostomuodot, jotka aidosti toimivat eri toimisto-ohjelmistoilla. Jos nyt joku uskoo, että Microsoft haluaa tätä, on se sama kuin uskoisi joulupukkiin.

Omalla ”standardillaan” MS yrittää vaan varmistella etulyöntiasemaansa ja virittää asiakirjoihin suljettuja toiminteita. Lohdutukseksi suljetuista osuuksista MS lupaa olla haastamatta ketään oikeuteen.

Microsoftilta on kestänyt kymmenen vuotta kehittää tämä oma näkemyksensä ”avoimuudesta”. Miksi heillä on nyt kiire standardisointikäsittelyn suhteen?

Eniten ihmettelen heitä, jotka haluavat nykyisenkaltaisen asiakirjojen yhteensopimattomuuden jatkuvan, vaikka eivät ole edes Microsoftin palkkalistoilla.

ja jos herra Mäntylahti (Tietokone-lehden toimittaja/avustaja?) ei ymmärrä standardien miellekkyyttä, niin se lähinnä hänen oma, henkilökohtainen ongelmansa. Ja silloin kyllä suosittelisin miettimään asioita enempi ja kirjoittamaan niistä vähempi – ainakin julkisesti.

Tyh(m/j)yys kun paljastuu useimmiten vasta sen julkitulon myötä… puhumalla tai kirjoittamalla esim… eli kantsis harkita ’suun suppuun’ laittamista.

Eiköhän jokainen tietotekniikka-alalla pitempään työskennellyt näe aika selvästi mistä tässä on kyse. Jos tämän standardin käsittelyssä olisi ollut kyse asiasta ja yrityksestä joka olisi jo vuosia ajanut reilua kilpailua ja asiakkaan parhaaksi tiedostomuotojen avoimmuutta ja standardointia, ei tämänkään asian kanssa varmastikaan olisi ollut mitään ongelmaa. Kuten jokainen alalla pitempään työskennellyt tietää, asian laita on juuri päin vastoin, ja kyseinen yritys on vuosikymmeniä käyttänyt tiedostomuotoja ja ohjelmistopatentteja kilpailulta suojautumiseen määräävässä markkina-asemassa, varsin menestyksekkäästi.

Ainoa kiinnostava asia tässä ovat ne valtion käyttäjäorganisaatiot jotka toimivat selvästi omaa ja kansalaisten etua vastaan. Millaisen prosessin kautta VM ja KTM päätyivät omaan suositukseensa? Siinä olisi tutkivalle tekniikan journalistille asia jonka voisi selvittää heti omalla takapihalla.

”Tutkiva journalismi” hmm…

Se on jotakin, mikä kuoli sukupuuttoon kvartaalitalouden alkuvaiheissa. Ottaako Tietokone-lehden toimituksesta joku haasteen vastaan?

Ane K. Dootti:

Mitä haluaisit asiassa tutkittavan? Toimittajan osaamisella ei lähdetä ainakaan 6000-sivuista standardia purkamaan.

Tietokone-lehti oli muuten melkein ainoana tiedotusvälineenä paikalla OOXML-tilaisuudessa eilen.

”Millaisen prosessin kautta VM ja KTM päätyivät omaan suositukseensa? Siinä olisi tutkivalle tekniikan journalistille asia jonka voisi selvittää heti omalla takapihalla.”

Tuohon viittasin. En tosin usko, että kyse olisi pelkästä lobbaamisesta vaan paremminkin virkamiesten puutteellisesta ymmärryskyvystä.

Ihan vain VM:n ja KTM:n asiasta vastaavien haastattelukin olisi mielenkiintoinen. Otettaisiin esille juuri nämä OOXML:n ongelmakohdat ja pyydettäisiin herroilta/rouvilta kommentit.

Niiltä valtion virkamiehiltä/päättäjiltä voisi tosiaan kysyä perusteluita päätöksille. Eli miksi nopea käsittely vaikka formaatista on jo nopean käsittelyn aikanakin löydetty paljon virheitä (listoja virheistä löytyy monesta paikasta) ja formaatti itse on 6000 sivuinen järkäle mitä ei kovin hyvin lyhyessä ajassa edes käydä läpi.

Ossi Mäntylahti, tuo standardointi ei päde ohjelmointikieliin samalla tavalla kun ohjelmointikieli on työkalu ohjelmointiin ja eri ohjelmointikielet soveltuu ihan eri tavalla eri asioihin. Sahalla sekä vasaralla rakennetaan taloja mutta saha sopii paremmin lautojen katkomiseen kuin naulojen lyömiseen lautaan. Standardeja tarvitsee siis tarvitsee eri ohjelmointikielille, että implementaatiot olisi yhteensopivia.

Siinä sitten olisi oikeasti standardoimista, että saisi kääntöjärjestelmiä yhdenmukaiseksi. Ja ohjelmointikielten standardoinnin sijasta, rajapintojen standardointi olisi ensiarvoisen tärkeää. Ihan sama millä C:llä, Haskelilla tai Javalla niitä ohjelmoi mutta olisi kiva kutsua sieltä samaa rajapintaa, kääntää vapaasti haluamallaan ja kääntäjällä standardiksi tavukoodiksi jota alusta kuin alusta osaa hiekkalaatikoida. Maailmalle riittäisi myös yksi standardi tavukoodialustalle. Näen jo formaattisodan tulevan JVM:n ja CLR:n välille.

Mutta OOXML sitten tekee ihan samaa asiaa kuin ODF, asiakirjadokumentin formaatti jonka avulla olisi ihmisten helpompi vaihtaa informaatiota keskenään ilman tiedostomuotojen kanssa sähläystä. Tiesitkö, että ohjelmointikielet on kaikki esitetty ihan tekstitiedostoina? Niitä voi siis muokata ihan millä tahansa tekstieditorilla ilman sähläystä tiedostomuodosta toiseen.

OOXML nyt sitten ei tekisi muuta kuin jakaisi käyttäjiä kahteen leiriin sen mukaan mitä softaa käyttävät. Yksi standardi formaatti lisäisi kivasti kilpailua formaattia käyttävien softien välillä. Ainiin, sellainenhan on jo. XML pohjainen, implementoituna valmiina siihen vähemmistön käyttämään softaan ja monopolilkilpailijalla on myös XML rajapinnat käytettävissään joihin se oma hätäisesti rävelletty formaatti jolla tarkoitus pönkittää monopolia on tehty. Ei tarvisi muuta tehdä kuin ottaa olemassa oleva standardi käteen ja toteuttaa se ja maailma olisi parempi paikka. Ihmiset sitten kirjoittaa dokumenttinsa ja sorsakoodinsa ihan millä työkaluilla haluaa ilman murehtimista siitä saako niitä auki.

Pitääpä ihan ääneen kiittää Matti Kaarnattua hyvin perustellusta kommentista. Sellaisista blogimaailmassa näkee varsin harvoin. Jatkan kuitenkin argumentaatiota kommentoimalla, että C++:n ja C#:n välinen käyttötarkoitusero — tai edes syntaktinen eroavuus ei ole kovin merkittävä. Adan murteista nyt puhumattakaan.

Tutustuin eilen yhden illan verran tähän standardisointiasiaan ja on sanottava, että tämä on turhankin suurten tunteiden värittämä. Asiaa vastustetaan kiihkomielisesti koska se tulee ”Suurelta Pahalta”. Kun keskustelua käydään anti-MS -laput silmillä, aletaan poimia argumentteja, joita ei itse tunneta. Esimerkkinä tämä vuoden 1900 edeltävien vuosien ongelma. OOXML-tiedostoihin *pystyy* syöttämään vuosilukuja, jotka ovat ennen vuotta 1900. Ongelma on siinä, että niiden *viikonpäiviin* vaikuttaa off-by-one -virhe. Eli kysymys on teknisestä bugista, eikä suinkaan ”juutalaisten ja islamilaisten tietoisesta sortamisesta”, kuten eräissä fundamentalistikommenteissa on näkynyt.

OOXML:n suurin etu ODF:ään verrattuna on se, että se on alan de facto -standardin (Docit, Xls:t ja Powerpoint-tiedostot) kanssa yhteensopiva. Tämä on merkittävä tekijä ja sen tärkeyttä ei saisi unohtaa. On toki huomattavasti helpompaa kehittää tiedostomuotostandardi puhtaalta pöydältä. Mutta kuvitteleeko joku todella, että kaikista maailman dokumenttitiedostoista tulee sormia napsauttamalla ODF:iä, varsinkin kun alan johtava toimisto-ohjelmapaketti ei tätä suoraan tue?

On kuitenkin selvää, että OOXML:ssä on olemassa teknisiä puutteita ja ne olisi hyvä korjata, ennen kuin se lyödään standardimielessä lukkoon. Tosin samaan hengenvetoon on kerrottava, että voittopuolisesti nämä tekniset puutteet liittyvät alaspäinyhteensopivuuteen ja esimerkiksi tiettyjen XML-elementtien attribuuttien heikkoon dokumentointiin.

Mitä monopolin pönkittämiseen tulee, niin muistaakseni OpenDocumentin täysi toteutus vaatii Java-virtuaalikoneen olemassaoloa ja sallii Java-appletit dokumenteissa. Ja kuten sanottua, Java puolestaan ei ole ISO- tai ECMA-standardi, joten on niitä teknisiä ongelmia nähtävissä ODF:nkin puolella.

- Ossi

Ps. Viikonpäiväbugia voi testata syöttämällä taulukkolaskentaohjelman soluihin päiväyksiä ja laittamalla niihin =WEEKDAY() -viitteen. Esimerkiksi 1.1.1800. Excel antaa erroreita 1.1.1900 edeltävistä päivistä ja myös Google Docs kompastelee noihin.

Lyhyt kommentti myös tähän:
”Tiesitkö, että ohjelmointikielet on kaikki esitetty ihan tekstitiedostoina? Niitä voi siis muokata ihan millä tahansa tekstieditorilla ilman sähläystä tiedostomuodosta toiseen.
”

Koetetaanpa seuraavia:
- Kirjoitetaan lähdekoodiin skandinaavisia merkkejä (vaikkapa kommenttikenttiin)
- Kirjoitetaan lähdekoodiin unicode-merkkejä (vaikkapa japaninkielistä tekstiä merkkijonomuuttujiin)
- Sisennetään tabulaattoreilla

- Luodaan sama tiedosto Windowsilla, Macilla ja Linuxilla ja yritetään avata ristiin.

Ja sitten ihmetellään miten kauniisti merkit menevät rikki, rivit pomppivat miten sattuu ja niin edelleen…

Ei tässä mistään kiihkomielisyydestä tai anti-MS:stä ole kysymys, vaan siitä että vihdoinkin saataisiin avoin asiakirjaformaatti joka toimii kaikissa toimisto-ohjelmistoissa.

Siihen on jo olemassa ISO-standardi.

Ohjelmointikielien sotkeminen tähän selkeään asiaan… no, kukin tyylillään.

Ja sovitaanko, että jätetään kaikki ”Iso Paha, tunteilu yms” kommentit jatkossa pois. Täällä sentään keskustelevat ammattilaiset, joilla on tarpeeksi kokemusta ja näkemystä sekä Microsoft että opensource-tuotteista. Moni käyttää ja ylläpitää kumpiakin päivittäisessä työssään.

Antaa virkamiesten ja muiden vihkiytymättömien keskustella mielikuvapohjalta.

Kiitoksia Ossi. Adaan en ole tutustunut, mutta joku C on esimerkiksi nykypäivänä vähitellen profiloitunut matalan tason kieleksi sulautettujen ympäristöjen ohjelmointiin ja matalan tason kirjastojen toteutukseen. C-kielisiä funktioita kun on niin helppoa kutsua muiden kielien FFI:n kautta.

C++, Java, C# ja D sitten ovat suunnattuja sovellusohjelmointiin olioparadigmalla ja ovat kyllä periaatteessa samaan tarkoitukseen suunnattuja. Mutta maailma ei nyt vaan ole täydellinen vaan jokaisen kielen käytännön toteutuksissa sitten on merkittäviä eroja miksi toinen kieli soveltuu tehtävään toista paremmin. Mutta sitten taas on esimeriksi dynaamisesti tyypitettyjä tulkattavia kieliä ja funktionaalisia kieliä joiden käyttötarkoitus ja ohjelmointitekniikka on täysin eri maailmasta

Ja kyllä, tekstitiedostojen kanssa on ongelmia. Niillä kun ei vaan ole standardia vaan ovat aikojen kuluessa muotoutuneet merkistö ja unix/dos/mac kohtaisiksi. Sorsakoodi tosin sitten on käytännössä US-english ja ASCII, ja lisäksi useimmat ohjelmointikielet usein paskat välittävät rivinvaihdoista. Mutta tosiaan, en nyt kaipaisi samaa pelleilyä toimistosoftiin mitä on asiakirjoilla tekstitiedostojen kanssa.

Eipä ne miljoonat dokumentit ihan heti mihinkään standardiin muutu, että kyllähän siinä joku kolme vuotta voi hyvin mennä ennen kuin standardia noudatetaan yleisesti. Kahdella standardilla sitten tämän lisäksi joutuisi pelleilemään tiedostomuotojen kanssa, jos edes sittenkään saisi järkevästi siirrettyä niitä dokumentteja. Todennäköisest OOXML /ODF käyttäjät jakaantuisi sen softan mukaan kahteen leiriin ja tämä hidastaisi molempien standardien toteuttamista. Voisi helposti jäädä se toinen standardi vähän vajaaksi kun on syytä olettaa, että noitakin joskus kymmenen vuoden välein vähän päivitetään.

ODF:n Javariippuvaisuus kuullostaa kyllä ensiksi ikävältä mutta toisaalta, C# on kyllä standardoitu mutta .NET ei ole, ja lisäksi .NET:ssä on patenteilla suojattua tekniikkaa jolla Microsoft voisi halutessaan rajoittaa avoimien toteutuksien tekemistä. Joku Python taas voisi hyvinkin olla sopivampi kieli tuohon asiakirjoihin, mutta ei silläkään mitään standardia ole.

Matti

Niin, siis kannattaa tässä erottaa mitä tarkoittaa c-kielen ja dokumenttiformaatin standardointi. C-kielen standardi on tavallaan yksi versio c-kielestä, jota noudattamalla päästään ja päästiin eroon erilaisista murteista ja käytännöistä. Paljon turhaa työtä ja turhautumista säästettiin kun pystyttiin sopimaan kustakin eri standardiversiosta. Mutta huomatkaa että kyseessä ei ole ohjelmointikielen standardi, vaan ainostaan c-kielen standardi, eli muoto miten c-kielistä ohjelmaa tulisi kirjoittaa ja tulkita. Ohjelmointikielen standardoimisessa ei olisi paljoakaan järkeä, sillä eri kielet ovat syntyneet eri tarpeista.

Dokumenttiformaatti toisaalta kannattaa standardoida, jotta taas säästettäisiin turhaa työtä ja turhautumisia, kun ymmärretään kunnolla mitä joku toinen on yrittänyt viestittää dokumenteissaan. Mutta miksi dokumenteille olisi useita eri standardeja (eri versioita tietysti voisi olla samasta dokumenttiformaatista)? Ehkä siksi että niillä formaateilla täytetään eri tarpeita. Mutta tässä tapauksessa ooxml ja odf ajavat täsmälleen samoja asioita. Vai ajavatko? Microsoftin erityistarpeet sitten ovat asia erikseen.

Ossin olisi syytä tutustua faktatietoon siitä, miksi OOXML ei voi olla ISO-standardi. Sitä ei voida ilman reverse engineeringiä yksinkertaisesti toteuttaa muihin ohjelmiin. Tässä rautalankaa asiasta:

http://www.robweir.com/blog/2007/08/dog-that-didnt-bark.html#7336650502950986976

Tilanne on täysin sama kuin binääri-DOC/XLS/PPT-muotojen kanssa. Miksi tällaisesta muodosta pitäisi tulla ISO-standardi?

Ja tämä on se syy, miksi OOXML vaatii paljon korjausta sekä formaattiin että spekseihin, ennen kuin se voidaan hyväksyä.

Pete, haaskaat aikaasi. Tietokone-lehden virallinen kanta on:

Windows/Office = HYVÄ
Linux/OpenOffice = PAHA

Kaupallisuus = HYVÄSTÄ
Avoimuus = SAATANASTA

Ainakin tämän kuvan olen lehden pitkäaikaisena lukijana saanut.

Sen ohella, että useampi samaa asiaa tekevä standardi häiritsee kilpailua ajamalla eri formaattien käyttäjiä eri leireihin ja että ihmisten elämä hankaloituu, tämä kiteyttää aika hyvin miksi en OOXML:stä toivo standardia:

http://openstandards.wikidot.com/definition

Ruotsissa näköjään tehdään muutakin kuin painetaan lehdistötiedotteita: http://www.nyteknik.se/art/52026

Valtionhallinnon kannattajat ja vastustajat kuvaavat varsin hyvin kysymystenasettelua:

Kansallisarkisto ja kansalliskirjasto ajattelevat asiaa pitkällä aikavälillä. Heillä tulee olemaan nykypäiväämme kuvaavia arkistoja täynnä doc/docx-tiedostoja joskus vuonna 2050 tai 2100, kun viimeinenkin PC on maatunut ja Microsoft historiaa tai aivan muun työn parissa. Silloin näiden tiedostojen tulkinta vaatii selkeää standardia, jonka pohjalta voi vaikka rakentaa uuden ohjelman tulevaisuuden kvanttitietokoneille tms. tulkitsemaan nämä tiedostot. (Vrt. Itä-Saksan tietokonearkistojen menetys) Tällä hetkellä OOXML on docx-tiedostojen osalta epätarkka, eli mahdoton toteuttaa ilman MS Officen lähdekoodin tarkastelua.

”OOXML:n suurin etu ODF:ään verrattuna on se, että se on alan de facto -standardin (Docit, Xls:t ja Powerpoint-tiedostot) kanssa yhteensopiva.” Ossi Mäntylahti

Tämä taas on valitettavasti täyttä hölynpölyä, sillä vanhojen Office-tiedostojen osalta – joilla siis tällä hetkellä on tallennettu suurin osa tiedostoistamme – OOXML-standardi sisältää vain merkinnät tyyliin ”näiltä osin kuten Word 97″ yms. ilman vihjettäkään miten ne tulkitaan. Eli kun viimeinenkin MS Officea pyörittävä kone on romua, nämä tiedostot ovat pelkkää bittisaastetta. Silloin auttaa enää kaivaa nykyisen Openoffice.orgin konvertointifiltterien lähdekoodit ja rakentaa tulkit siltä pohjalta. OOXML on siis siltä osin hyödytön.

Näin ollen, koska edessämme on joka tapauksessa siirtyminen uuteen tiedostoformaattiin, OOXML:ään tai ODF:ään, tuntuu jotenkin turvallisemmalta siirtyä formaattiin, jota pystyy lukemaan useammalla ohjelmalla, ja jonka standardi on kohtuullisen selkeä ja yksioikoinen, eli ODF:ään. Myös MS Officeen on saatavilla jo suodattimet, joilla ODF-tiedostoja luetaan ja kirjoitetaan.

Kauppa- ja teollisuusministeriö sekä valtiovarainministeriö ja tullihallitus taas ajattelevat vain nykypäivän ongelmiaan. He ehkä luulevat Ossi Mäntylahden lailla, että OOXML:n standardointi säästäisi heidät konvertoimasta miljoonia tiedostoja uuteen formaattiin, koska sittenhän tämä nykyinen olisi ”virallinen”. Ja kaupan alan, eli Microsoft-pahvilaatikoita myyvien yritysten tukeminen on tietenkin myös lähellä heidän sydäntään, kun avoimen lähdekoodin ohjelmat eivät tunnu tuottavan liikevaihtoa.

Mutta samalla tavalla kansantaloutta voisi edistää säätämällä käsijarrujen päällä pitäminen ajaessa pakolliseksi, koska se lisää bensiinin myyntiä ja autokorjaamoiden liikevaihtoa…