<p>
    Sono lieto di ricevere da parte di Andrea Valboni di Microsoft alcuni commenti al <a href="http://www.piana.eu/?q=it/commenti_ecma">mio precedente post</a> sulla questione OOXML. La risposta, tuttavia, non mi convince del tutto.
  </p>
  
  <p>
    Mi soffermerò solo su una singola, centrale problematica, invece di avviare una discussione multi-tematica. <strong>Non ci possono essere due Standard Internazionali</strong>. In effetti in passato si sono avuti due o tre differenti standard industriali. Ma cos'è successo? <strong>Solo uno è sopravvissuto</strong>. Il migliore? Non sempre, e con quale spreco di risorse nel frattempo. Il chiaro esempio del VHS, che ha avuto la meglio sul Betamax con l'estromissione dello standard migliore a vantaggio di quello peggiore, dovrebbe essere già indicativo. E quando dico &#8220;peggiore&#8221;, non è solo una questione di gusti.
  </p>
  
  <h3>
    Due standard o uno standard? Questo è il problema
  </h3>
  
  <p>
    A volte lo standard migliore batte lo standard peggiore. Il <a href="http://en.wikipedia.org/wiki/Blue_ray">Blue Ray</a> sta superando l'HD DVD<a href="http://en.wikipedia.org/wiki/HD_DVD"></a>. Ma durante il processo di standardizzazione un sacco di risorse sono state impiegate in quella che è una lotta priva di senso. E non sto parlando delle due aziende che propongono i due standard, so parlando di coloro che hanno iniziato a implementare uno dei due standard senza avere alcuna rassicurazione che la loro scelta sia la più opportuna; e parlo anche dei consumatori, i quali in una parte non irrilevante di casi acquistano qualcosa che è destinato a rivelarsi inutilizzabile a causa della mancanza di contenuti. Infine, bisognerebbe considerare il ritardo causato da questa <a href="http://en.wikipedia.org/wiki/Format_war">battaglia degli standard</a> per una tecnologia che era già matura almeno un anno fa.
  </p>
  
  <p>
    Ciò è abbastanza consueto in ambito di concorrenza industriale. Qualcuno si fa avanti con la sua proposta, poi il mercato decreta chi ha la meglio. Microsoft è molto brava in queste cose, usando una lunga lista di strategie commercialmente corrette, a volte al limite e in qualche caso oltre il limite (secondo il giudizio definitivo di Corti molto autorevoli).
  </p>
  
  <p>
    Ma nel caso di Standard Internazionali, il più autorevole, rispettabile e indipendente tipo di standard, non è proprio la stessa cosa: il fatto stesso di cercare di imporre OOXML come Standard Internazionale alternativo rispetto a uno già esistente, per esattamente lo stesso campo di applicazione &#8212; come è ODF &#8212; vuol dire causare problemi di concorrenza. Non devono esistere due Standard Internazionali per lo stesso identico campo di applicazione, perché ciò è:
  </p>
  
  <ul>
    <li>
      <strong>anti-economico</strong> per coloro che implementano lo standard: o restando non interoperabili con uno dei due, oppure dovendo supportare contemporaneamente due differenti standard incompatibili;
    </li>
    <li>
      in questo caso lo <strong>standard vincente</strong> non sarà verosimilmente quello più interoperabile, più libero e in generale migliore, ma quello sostenuto dall'<strong>applicazione dominante</strong>.
    </li>
  </ul>
  
  <p>
    In tutti gli esempi di Standard Internazionali in sovrapposizione (eccetto forse uno o due casi), essenzialmente essi hanno profonde differenze e perseguono differenti obbiettivi. Si pensi ad esempio al dualismo di <strong>TCP e UDP</strong>: teoricamente ciascuno dei due può essere usato per gran parte delle applicazioni per cui è usato l'altro. Essi hanno tuttavia speculari vantaggi e svantaggi, che fanno l'uno più adatto dell'altro se si ricerca l'affidabilità sulla leggerezza e le prestazionei, e viceversa. Qualche volta ci sono più standard per un singolo dominio applicativo, come <a href="http://en.wikipedia.org/wiki/Jpeg">JPEG</a> e <a href="http://en.wikipedia.org/wiki/Jpeg2000">JPEG2000</a>. Ma questa duplicità di standard riflette l'evoluzione della tecnologia, in questo caso col passaggio dalla codifica DCT alle Wavelets, cosa che rende più efficace la rappresentazione in un campo specifico.
  </p>
  
  <p>
    Con l'OOXML e l'ODF ciò non accade, dato che entrambi sono diverse rappresentazioni sintattiche delle stesse strutture di base e semantica (le differenze, dove sussistono, sono piuttosto sottili).
  </p>
  
  <h3>
    &#8220;È l'implementazione, stupido&#8221;!
  </h3>
  
  <p>
    Ah, ok! Allora mi sembra di capire quale sia l'idea che Microsoft sta cercando di far passare. Chiedo scusa, non avevo prestato sufficiente attenzione. L'OOXML deve essere approvato in <em>fast track</em> perché c'è una marea di utenti e sviluppatori là fuori che stanno dicendo: &#8220;dobbiamo generare output per l'applicazione dominante&#8221;. Non perché sia migliore o perché esso permetta di fare cose che non si possono fare in altro modo, ma perché lo standard segue un object model vecchio di 25 anni di un'unica applicazione, e bisogna in qualche modo conservare gli script e le applicazioni che generano dati e documenti compatibili con Office, oggi, e domani con Office 2007&#8243; (nota: non ho detto &#8220;con OOXML&#8221; o &#8220;con DIS29500&#8221;). Da qui – per esempio – la necessità di preservare il bug noto come &#8220;il 1900 è un anno bisestile&#8221; ignorando bellamente che a) da un bel po' siamo nel <a href="http://en.wikipedia.org/wiki/Gregorian_calendar">calendario Gregoriano</a> e non nel calendario Giuliano, e b) esiste uno standard ISO (<a href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=40874">8601</a>) sulla rappresentazione delle date che non può essere trascurato. In altre parole, <strong>è l'implementazione che definisce lo standard, non lo standard che definisce l'implementazione</strong>, e questo è semplicemente inaccettabile.
  </p>
  
  <p>
    Sarò anche prevenuto, ma uno standard che ignori tutti gli standard e addirittura tutte le regole dei processi di standardizzazione, non dovrebbe essere uno Standard Internazionale. Come ho detto, mettere un timbro su uno standard in fretta e furia per procurare un bagliore di &#8220;indipendenza&#8221; e &#8220;apertura&#8221; ad un standard mono-produttore (cioè sviluppato da un unico soggetto) è fuori dagli scopi dell'ISO. Questa è la mia idea. Gli altri sono liberi di avere la loro. Tuttavia io ho ragione e loro hanno torto. 😉
  </p>
</div>