In un precedente articolo in cui riportavo delle riflessioni su una notizia riguardante il plugin ODF di Oracle per Microsoft Office, è stata sollevata da un lettore (commento #13) la presunta mancanza di (piena) aderenza allo standard da parte del filtro di importazione realizzato da quest’ultima per la versione 2007 del suo noto pacchetto.
Si tratta di un’accusa che circola da tempo nei confronti della casa di Redmond, che a questo punto merita di essere analizzata e sviscerata alla luce del draft ufficiale dell’ODF (che trovate qui) e delle critiche che le vengono mosse.
Alcune di queste si trovano in un documento redatto dall’ODF Alliance che ne racchiude le tre più importanti, sostenute da diverse altre fonti anche autorevoli, come ad esempio Rob Weir di IBM, a capo della ODF Technical Committee, e che in proposito ha scritto due articoli (che trovate qui e qui) che esaminano nel dettaglio la più controversa delle tre, cioè quella relativa alle formule presenti nei fogli di calcolo.
Doug Mahugh di Microsoft spiega nel suo blog in che modo le formule sono implementate in Office 2007, e le motivazioni che hanno portato a quelle scelte, con esempi concreti e riferimenti ad altre implementazioni.
Al di là delle opinioni personali, per dirimere la questione penso sia necessario affidarci all’unico strumento che uno sviluppatore dovrebbe prendere in considerazione: il draft dello standard, per la lettura e comprensione del quale è necessario valutare per bene il significato e il peso delle parole utilizzate.
La parte che descrive sintassi e semantica delle strutture da utilizzare per racchiudere le formule si trova a partire da pagina 186 (“Formula”), all’interno della sezione 8.1.3 (“Table Cell”), che recita:
Formulas allow calculations to be performed within table cells. Every formula should begin with a namespace prefix specifying the syntax and semantics used within the formula. Typically, the formula itself begins with an equal (=) sign and can include the following components:
segue un elenco di possibili elementi e alcuni esempi. Mi sono permesso di evidenziare due parole, che rappresentano la chiave di lettura delle frasi in cui appaiono, e che sono state la fonte delle polemiche.
Chi ha avuto a che fare coi documenti ufficiali, conosce bene il significato del verbo should, che nello specifico non assume un valore condizionale, ma imperativo e, quindi, vincolante. Indica, infatti, un requisito che lo sviluppatore deve obbligatoriamente implementare secondo le indicazioni che vengono fornite, altrimenti non viene soddisfatta l’aderenza allo standard.
Pertanto una formula deve necessariamente far uso di un namespace che ne definisca la struttura sintattica e semantica, in modo tale che il parser possa essere in grado di interpretarne correttamente il contenuto.
Appare di tutta evidenza che questo meccanismo consente di definire formule aventi strutture diverse, persino all’interno dello stesso documento o addirittura fra le celle di una stessa tabella (o foglio).
Quest’enorme flessibilità che ne dovrebbe rappresentare un innegabile punto di forza si trasforma, però, in una pesante pietra al collo che è stata messa al concetto di interoperabilità, e il motivo mi sembra a dir poco lapalissiano.
Se ogni software house può decidere in che modo memorizzare le formule del suo applicativo nei file ODF, allora queste saranno interpretabili soltanto da programmi dotati di appositi parser. Basta, pertanto, che ognuno scelga un proprio formato, essendo l’unico a supportarlo, e il gioco è fatto: risulteranno illeggibili dagli altri.
Ovviamente, non so se per ignoranza (non si può conoscere tutto), buona fede, o volutamente, questo dettaglio spesso non viene citato e viene riportata, invece, la frase seguente, che però inizia per typically e fornisce poi un esempio di come potrebbe (e qui il condizionale ci sta tutto) essere strutturata una formula.
Il significato del vocabolo in questione è decisamente chiaro, e non potrebbe essere altrimenti: se lo standard prevedesse rigidamente un ben preciso formato, la parola usata non sarebbe certamente “tipicamente”…
Eppure le critiche che si leggono in giro giocano per lo più su questa frase, che a loro dire indicherebbe il formato da utilizzare, e servendosi dell’esempio fornito nella documentazione come “prova”: il formato è quello. Non si scappa.
Si tratta di un comportamento che, a voler essere buoni, è possibile etichettare come ingenuo, o come intellettualmente disonesto per chi, pur conoscendo i termini della questione, continua a propinare delle autentiche falsità pur di difendere ciecamente fantasie o ideologie che di carattere tecnico non hanno nulla a che spartire.
Rob Weir, che ho citato prima, arriva addirittura a sostenere che uno standard può anche essere ambiguo, e che non sarebbe giusto approfittare di ciò per minarne l’interoperabilità, citando come esempio l’HTML, che non specifica il colore del background (iniziale).
Questo signore, nonostante la posizione che ricopre, mostra scarsa conoscenza sia dell’HTML che della realizzazione degli standard. Per il primo perché dovrebbe ben sapere che HTML non nasce come standard di presentazione di documenti, cosa che avverrà soltanto anni dopo con l’introduzione di qualche tag e, meglio ancora, dei famigerati fogli di stile.
Il secondo, e ben più grave, è il fatto che uno standard nasce proprio per mettere ordine e dovrebbe essere quanto di più chiaro e meno ambiguo possibile, per permettere a chiunque di implementarlo e favorendo, appunto, l’interoperabilità.
Giusto per fare un esempio, è come se il comitato che ha realizzato il JPEG avesse definito tutto a puntino, ma omettendo la trasformata da applicare ai dati. Oggi ci sarebbe chi avrebbe scelto la DFT, chi la DCT, e altri ancora che avrebbero potuto andare a pescare dal calderone delle centinaia di trasformate wavelet finora a disposizione.
Il caos, insomma, come potete immaginare. La verità è che il gruppo che ha realizzato l’ODF ha commesso un madornale errore, lasciando aperta un’enorme falla che ha, di fatto, buttato nel cestino tutti gli sforzi atti ad arrivare a un formato che garantisse l’agognato Santo Graal: l’interoperabilità.
Le altre due critiche sono meno importanti, ma val la pena di analizzarle e spendere qualche parola per riportare analoghe conclusioni. Liquidiamo subito il più semplice che riguarda le “tracked changes”, cioè l’elenco delle modifiche apportate in un documento.
A pagina 78, nella sezione 4.6 (” Change Tracking”), si legge subito:
This section describes how changes in text documents can be represented.
dal termine che ho evidenziato si capisce subito la natura facoltativa della funzionalità, che se obbligatoria avrebbe dovuto usare, invece, should o specificare mandatory, com’è in uso in questi casi.
Essendo il supporto non vincolate, chi implementa l’ODF può, quindi, legittimamente evitare di prendere in considerazione quest’aspetto, rimanendo in ogni caso nella “legalità”, cioè nel rispetto dello stesso.
Merita più attenzione l’ultimo punto, quello che riguarda il mancato supporto alla crittazione con password dei documenti. Le informazioni su questa parte si trovano a pagina 698, sezione 17.3 (“Encryption”), ma prima bisogna fare un salto alla pagina precedente, che introduce il capitolo 17 (“Packages”) e dove si legge immediatamente:
This chapter describes the package format that optionally can be used in OpenDocument.
Qui, oltre al verbo can, che sarebbe già di per sé sufficiente a dirimere la questione, si sono sbottonati con un ridondante optionally. Si tratta, ancora una volta e inoppugnabilmente, di caratteristiche opzionali che la software house può, quindi, evitare di implementare.
Oltre alla crittazione troviamo quindi la compressione in formato zip di tutti i file facenti parte del documento, come l’immagine di preview. Tutto opzionale. Rimane da capire se il comitato si sia reso conto delle conseguenze che avrebbe la mancata adozione dello ZIP, in quanto facoltativo, sulle dimensioni di un documento.
La cosa si commenta da sé ed evidenzia la leggerezza, ma soprattutto l’inadeguatezza delle persone che sono state chiamate a definire questo “standard” che, da quanto detto, preferisco prender con le pinze usando le virgolette col termine.
Finita la disamina delle critiche, che sono state dimostrate del tutto infondate, all’implementazione ODF di Microsoft, riporto una critica che è stata mossa questa volta all’ODF, e che riguarda proprio l’adozione dello ZIP come struttura per archiviare tutti i file di un documento.
Ebbene, la beffa si aggiunge al danno se riflettiamo sul fatto che questo formato non è mai stato standardizzato, come si può leggere dall’apposita nota che rimanda a questo indirizzo, a cui tra l’altro nemmeno si può accedere (non permette di autenticarsi come utenti anonimi).
Poco importa (ma non per un documento standard, che dovrebbe essere quanto meno accessibile), perché con una rapida ricerca è possibile recuperarne una copia in qualche mirror. Aprendo il file ci si rende conto dell’ovvio (per chi ha studiato il formato ZIP), in quanto si tratta del documento di testo denominato “Info-Zip” che all’inizio recita:
Info-ZIP note, 970311: this file is based on PKWARE’s appnote.txt of 15 February 1996. It has been unofficially corrected and extended by Info-ZIP without explicit permission by PKWARE.
da cui risulta piuttosto eloquente l’ultima frase (in particolare nella parte evidenziata).
In ogni caso si tratta del lavoro fatto da un gruppo di persone che hanno applicato tecniche di reverse engineering agli archivi generati dal famoso programma che ha introdotto questo formato, realizzato da PKWARE, e lo stesso documento afferma che vi possono essere informazioni non accurate o errate.
Ricapitolando, abbiamo un documento ufficiale (ISO) che sui tre punti chiave e oggetto di discussione lascia completamente mano libera all’implementatore, e che si affida a un formato, quello ZIP (in ogni caso opzionalmente utilizzabile come contenitore), che a sua volta non è mai stato standardizzato (è soltanto uno “standard di fatto”, sebbene sia il più diffuso).
Il risultato è un documento che introduce uno standard che, di fatto, è inutilizzabile ai fini dell’interoperabilità. Se consideriamo che era proprio questo l’obiettivo con cui era stato approntato, possiamo affermare senza alcun dubbio che è un completo fallimento.
Il comitato sta lavorando alla versione 1.2 che dovrebbe porre rimedio (ma non alla standardizzazione del formato ZIP), ma ormai la frittata è fatta, perché esistono già documenti e applicazioni che adottano la 1.0 o la 1.1 (quest’ultima mai standardizzata).
Per rendere l’idea, quando la 1.2 sarà standardizzata ci si troverà in una situazione simile a quella che si ha attualmente col JPEG e il suo successore, il JPEG 2000. Sarebbe meglio utilizzare quest’ultimo in quanto molto più efficiente, robusto e versatile, ma il primo è estremamente diffuso e non si potrà interromperne il supporto; di conseguenza la gente, per essere sicura che chiunque potrà vedere le sue immagini, continuerà a utilizzare il primo, rendendo di fatto inutile il secondo…
azz, non ho il tempo di leggerlo tutto per bene ma le conclusioni mi sembrano sconfortanti…!
è davvero così brutta? Ma (la faccio semplice visto che non ne so niente) un formato open non dovrebbe risolvere il problema di compatibilità per sua natura? Chiunque ne prende i sorgenti e scrive un interprete ad hoc…… o no?
@n0v0: nella pratica si, visto che al limite puoi sempre leggerti i sorgenti di openoffice e non penso che openoffice non implementi pienamente odf
@Cesare Di Mauro: complimenti per l’interessante articolo, trattato con la consuetà lucidità che ho sempre riscontrato nelle tue analisi.
Il link al blog di Doug Mahugh è stato particolarmente illuminante!
Mi resta solo un dubbio circa le consclusioni:
[QUOTE]
Ricapitolando, abbiamo un documento ufficiale (ISO) che sui tre punti chiave e oggetto di discussione lascia completamente mano libera all’implementatore, e che si affida a un formato, quello ZIP (in ogni caso opzionalmente utilizzabile come contenitore), che a sua volta non è mai stato standardizzato (è soltanto uno “standard di fatto”, sebbene sia il più diffuso).
Il risultato è un documento che introduce uno standard che, di fatto, è inutilizzabile ai fini dell’interoperabilità. Se consideriamo che era proprio questo l’obiettivo con cui era stato approntato, possiamo affermare senza alcun dubbio che è un completo fallimento.
[/QUOTE]
Risultato dettato da incompentenza/ignoranza/ingenuità o da volontà?
#n0v0
dipende dai casi, a volte è molto meglio reinventare la ruota, che cercare di capire come gira quella esistente…..,
Non voglio pensare che all’ISO ci siano persone così incompetenti da creare uno standard così “aperto” nel senso di discrezionale.
Credo si possa ipotizzare che siano volate mazzette per farlo apposta così, e proprio Microsoft, guardacaso, legittimata proprio da queste frasi ambigue ha implementato diversamente ODF in office quando se fossero in buona fede ed attenti all’interoperabilità avrebbero visto e/o collaborato con il team di openoffice.
> avrebbero visto e/o collaborato con il team di openoffice
Ma se sono quelli di Openoffice che dovrebbero darsi una regolata se vogliono rincorrere un software closed come Office…
Quoto Massimo C.
Ricordo inoltre che mazzette sono volate anche quando era ora di approvare OpenXML.
Molti standard sono buffonate di documentazione interpretabile. Uno standard andrebbe specificato con codice sorgente: una implementazione studiabile e univoca o quantomento un linguaggio formale (vedi SNMP e ASN.1).
Guardacaso un implementazione di riferimento c’è per ODF e si chiama OpenOffice.org. Se MS fa documenti che non girano su OpenOffice è sicuramente vizio di MS.
Se ci sono incoerenze vanno corrette ed eventualmente se MS trova il modo di fare meglio qualche cosa non ha che da presentare una patch per OOO.
HTML pure dovrebbe essere gestito così: un browser di riferimento che incarna lo standard. Se qualche browser renderizza diversamente, allora è un baco suo.
Non ci deve essere un “unico strumento che deve prendere in mano lo sviluppatore”, ovvero una documentazione in linguaggio naturale.
Per ricapitolare sono stati poco furbi quelli di ISO e ODF a lasciare libertà e incertezza, mentre sono in cattiva fede quelli di MS, come al solito.
@Ruppolo
Non mi riferivo all’implementazione delle feature di office e/o alla compatibilità con i formai suoi (proprietari microsoft), ma bensì al’implementazione da parte di Microsoft di un formato aperto in un modo tale da non essere pienamente compatibile con l’implementazione di Openoffice.
Cioè invece di mantenere la ratio per cui è nato ODF e quindi implementarlo allo stesso modo di openoffice, hanno deliberatamente scelto di essere incompatibli. E l’articolo ci spiega che sono anche legittimati a farlo data la discrezionalità della specifica in alcuni punti.
@Andrea R
Basterebbe scrivere le specifiche in un modo tale da non poter essere interpretate in modi troppo diversi o non poter essere interpretate affatto. A prescidere dal fatto che ci sia o no un’implementazione di riferimento.
Segno che dare troppa libertà agli sviluppatori a causa di specifiche non completamente esaurienti può creare problemi.
@AndreaR: se implemento ODF ma le specifche di quest’ultimo mi lasciano completa libertà di scelta su alcune cose delicate, non è certo dello sviluppatore la colpa, quanto di chi ha steso le specifiche.
La definizione di specifiche è materia complessa e ambigua per tutti. Ogni azienda (o gruppo di aziende) ha interesse a “giocare in casa” coi formati.
Ricordo che lo stesso Office 2007 dopo la ratifica ISO di OOXML, generava un log di 120.000 errori di conformità (http://www.appuntidigitali.it/1465/office-2007-incompatibile-con-ooxml-qualche-riflessione/): dunque quanti dei risultanti file OOXML prodotti con le versioni non patchate di Office 2007 saranno poi effettivamente utilizzabili da piattaforme terze che supportano il formato?
Possiamo, allora come oggi, dare per supposta la buona fede?
Nel frattempo fra imprecisioni, leggerezze e pressioni indebite, credo che l’ISO abbia perso una bella fetta della sua credibilità.
@n0v0: un formato “open” è, appunto, quello di ODF, le cui specifiche sono aperte. Non sono necessari i sorgenti di un’implementazione per definirlo.
In ogni caso, e come dimostra l’articolo, questo non è sufficiente: dev’essere anche non ambiguo e/o non lasciare appositamente punti liberamente interpretabili.
@pabloski: quando si parla di standard il procedimento è esattamente inverso. Non si passa dai sorgenti al documento, ma al contrario: è da quest’ultimo che chiunque, interpretando il documento, ne realizza un’implementazione.
@banryu: il mio giudizio l’ho espresso, comunque personalmente propendo per l’incompetenza.
@Massimo C: l’articolo l’ho scritto per dimostrare, appunto, quanto sia discrezionale ODF come standard, minando l’interoperabilità.
Quello delle mazzette è un’altra, classica, leggenda metropolitana che circola. Giusto per essere chiari, e come puoi trovare tu stesso con una ricerca, alcune proposte di Microsoft sono state bocciate da IBM e Sun. A dimostrazione che queste due non hanno voluto “interferenze” nella definizione di ODF.
@Andrea R: uno standard è normalmente dotato di un documento che lo descrive in tutti i punti e che può benissimo essere non ambiguo, come pure adottare notazioni come l’usatissima EBNF. Quella dei sorgenti che specificherebbero uno standard è una storia che mi suona nuova e, “casualmente”, proprio adesso che ho scritto quest’articolo.
@Giulio85: hai centrato perfettamente i termini della questione.
@Alessio: il problema di OOXML è diverso, e anche qui la precisa storia è poco nota.
In estrema sintesi, OOXML prevede due “profili”, chiamati “transactional” e “strict” (se non ricordo male; è passato un po’ di tempo da quando mi sono documentato).
Microsoft adotta soltanto il primo, e ne è conforme. Per il secondo non ha raggiunto la piena compliance perché da quando ha sottoposto le specifiche al comitato per la loro standardizzazione, sono state apportate tantissime modifiche, per cui Office 2007, che era già in gestazione da parecchio tempo e doveva essere rilasciato, è rimasto fermo soltanto al primo profilo.
Onestamente vi siete fatti un po’ di seghe mentali.
Io lavoro quotidianamente con gli standard ISO in ambito meccanico e vi assicuro che sono scritti da persone e anche loro sbagliano, considerato anche il fatto che gli standard meccanici sono tra i più antichi (50 anni) e consolidati.
Secondo me tra il dire che c’è uno standard che va così così ma si sta cercando di metterlo a posto e uno standard (docx) che non ha ancora un applicativo che lo legge secondo standard. Sono molto più contento del primo caso.
Alla fine sicuramente ci sarà la presenza di tutti gli standard ma con il passare del tempo ci si convertirà all’ultima versione. Alla fine la retrocompatibilità stretta, in scrittura, non è così obbligatoria perchè l’aggiornamento alle versioni precedenti è gratuito. Non come l’office che si dove pagare per passare da una versione a una più recente e per quello ti trovi ancora gente con office 95.
Se uno prende ad esempio emule dove sono dichiarati le versioni dei client che si hanno contattato, si noterà che non vi sono clienti veramente obsoleti. Questo è dovuto al fatto che l’avanzamento di versione non costa nulla.
@ Cesare
Anche nel test condotto da Griffin Brown in modalita transitional c’erano errori, 84 credo…
Complimenti per l’interessante articolo.
Mi permetto solamente di dissentire dall’interpretazione che è stata data, ad inizio articolo, alle parole estratte dal testo dello standard. Nella mia esperienza professionale passata, che mi ha visto dedicare diversi anni allo sviluppo di software di codifica video (nel mio caso specifico conforme allo standard ITU-T H.263), mi ricordo bene che i livelli di conformità espressi verbalmente erano tre (peraltro chiariti in un apposito paragrafo esplicativo, proprio per evitare interpretazioni):
– CAN: suggerimento circa una caratteristica/funzionalità la cui inclusione è lasciata alla discrezione dell’implementatore.
– SHOULD: potremmo definirla una “calda raccomandazione”; di solito ci si riferisce a modalità raccomandate di implementazione di una funzionalità o caratteristica di cui si assume la presenza (nel caso dello standard video di cui mi ero occupato, molte caratteristiche legate alla gestione degli errori erano marcate con SHOULD: non sei obbligato ad implementarle, però è evidente che nessuno utilizzerebbe un CODEC che non abbia almeno una basilare gestione di errori di sintassi nel bit stream).
– SHALL, MUST: queste sono le locuzioni che indicano esplicitamente parti obbligatorie di una implementazione.
Alla luce di questa convenzione a cui mi sono sempre uniformato, direi che la frase riportata in articolo “every formula SHOULD begin with…” andrebbe interpretata come un “caldo consiglio” circa la simbologia che determina l’inizio di una formula in una cella, ma questo consiglio non può assumere un valore vincolante.
A voi la parola.
Ciao
Filippo
Così è anche peggio… :D
@Alessio: si tratta di un banale errore.
http://www.linuxloop.com/tag/ooxml/
Il problema è dovuto alla ridefinizione di due valori, passando dall’OOXML già implementato a quello che è stato apportato dallo standard.
In ogni caso Microsoft deve provvedere quanto prima alla correzione, ovviamente, se vuole rimane nella piena compatibilità col profilo transitional.
Tempo fa invece si faceva un discorso sulla necessità di avere un’implementazione di un browser di riferimento per html, su OsNews. Non è una mia invenzione di adesso, ma la logica conseguenza di molte tematiche di ingegneria del software. Alla fine il codice è anche una specifica completamente dettagliata.
Poi se leggete ho scritto o implementazione o specifica in linguaggio formale come per SNMP. Altrettanto valido, ma poco redditizio a parer mio, un doppio lavoro.
Ovviamente l’errore nella specifica di ODF c’è, ma nel dubbio uno va a vedere l’implementazione di OOO. Altrimenti o è poco furbo o in cattiva fede. Io propendo per la seconda.
Non c’è alcun dubbio: il documento parla chiarissimo, e mi sembra che l’articolo dimostri in maniera inoppugnabile come non ci sia ambiguità, quanto piuttosto troppa “leggerezza” nella sua definizione.
Perché qui non è questione di interpretare una matassa di lana caprina: si tratta di funzionalità che sono state dichiarate OPZIONALI. Per cui chi implementa ODF ha piena facoltà di decidere se implementarle o meno, e non di vincolarsi al lavoro fatto da altre soluzioni software, pur rimanendo nella piena legittimità dello standard.
Per quanto riguarda gli standard, in genere sono accompagnati da test suite apposite in modo che chi li implementa abbia gli strumenti per verificare se il codice si comporta in maniera corretta o meno. In gergo questi strumenti vengono chiamati “verification model”.
Nello specifico, comunque, non servirebbero a nulla, come puoi intuire, perché la natura dei problemi è ben diversa.
Per quanto riguarda HTML, servirebbe un verification model, appunto, e non l’intero codice di un browser. In ogni caso, e come ho scritto nell’articolo, HTML non è certo nato per presentare i dati, ma per dargli una struttura e un significato semantico. E’ coi fogli di stile (CSS) s’è cercato di aggiungere anche questa caratteristica, che andrebbe testata (è quel che fa, in parte, la famosa test suite “Acid test”).
La cattiva fede di cui parli, pertanto, è da attribuire a chi pretende di imporre agli altri implementatori soluzioni adottate da una particolare soluzione, facendola passare come l’unica possibile e/o giusta.
Ripeto: qui stiamo parlando di standard, e quel che interessa è stabilire se tale standard è interoperabile o meno, e perché. Fine della questione.
Secondo me queste analisi lasciano un po’ il tempo che trovano. Il tono dell’artiocolo, magari, serve solo a screditare una suite a favore di un’altra.
In futuro, ODF 1.5 o ODF 2.0 forse avranno altri problemi cmq se potrai ancora aprire file in ODF 1.0 e trasformarli in ODF 1.X(senza perdere nulla) fanno quello che devono fare.
Alla fine OpenOffice e’ uno strumento gratis che usa ODF lo puoi installare pure su macchine + datate e quindi non vedo il motivo per continuare ad usare di default uno standard vecchio, ODF 1.0.
L’esempio JPG e JPG2000 non e’ la stessa cosa, infatti le software house hanno optato per mantenere JPG di default e JPG2000 optional (al contrario di openoffice molti software che producono JPG non sono gratis da aggiornare)
Aspettarsi che Microsoft segua uno standard internazionale è quantomeno una utopia. Solo un ingenuo può credere la cosa possibile.
TUTTA la storia di MS è segnata da pratiche anti integrazioniste con il resto del mondo. Avendo la posizione che ha è il metodo più semplice per il lock-in dell’utenza, quindi una pratica altamente redditizia n termini di vendite.
Volgiamo parlare dei suoi browser? Della VM Java? Dello standard alternativo all’OOXML approvato con il voto di Stati che mai si erano neanche presentati al tavolo di discussione? Dei suoi stessi formati che cambiavano 2 byte da una versione alla successiva per costringere all’upgrade?
La descrizione dell’informazione all’interno di un file non è tecnologia. Sarebbe bastato imporre alla MS di rilasciare la descrizione completa dei suoi formati di salvataggio. Ma ovviamente la cosa è impossibile. Ed è palese che per quanto il documento di descrizione dello standard ODF possa essere perfetto, MS troverà sempre la virgola a cui attaccarsi per non rendere il proprio formato interoperabile con il resto del mondo.
Forse che Sun non avesse dato una rigorosa descrizione di come fare la VM? Eppure è stata condannata per le modifiche che vi aveva apportato (modifiche atte al lock-in ovviamente). Forse che l’HTML e successivi CSS non sono stati documentati a dovere? Eppure ancora si aspetta un browser made in MS che si adegui a quello che fanno tutti gli altri.
Ora, che il documento allo standard ODF abbia falle è altrettanto palese. E MS non ha colpa per quello (a meno di non entrare nella questione della corruzione da dimostrare) e si possono trovare tutte le giustificazioni possibili al suo comportamento. Però sperare che anche se fosse stato scritto in maniera perfetta fosse stato rispettato mi sembra una cosa da ingenui.
MS sa bene che il proprio vantaggio sul resto dell’industria IT è che ha degli standard de-facto che non sono replicabili dagli altri (non per incapacità tecnica, ma perchè semplicemente non sono documentati). Scardinare questo assunto significa porre MS in competizione con una qualsiasi Software House che apre i battenti domani e comincia a sfornare ottime applicazioni che usano standard compatibili con tutto il mercato.
“Forse che Sun non avesse dato una rigorosa descrizione di come fare la VM? Eppure è stata condannata per le modifiche che vi aveva apportato (modifiche atte al lock-in ovviamente)”
Ovviamente intendevo che MS è stata condannata a non continuare a rilasciare la Java VM modificata.
Scusate l’ambiguità nella frase quotata.
@Kirk: l’articolo, se lo leggi bene, ha lo scopo opposto, cioè evitare che alcune implementazioni siano screditate additando la falsa accusa che non sarebbero aderenti allo standard.
In futuro, da quel che circola al momento come informazioni, sembra che ODF 2.0 sarà incompatibile con le versioni precedenti. Vedremo quando sarà finalizzato.
Lo standard “vecchio”, come lo chiami, è l’UNICO standard ISO disponibile al momento per l’ODF, per cui è anche l’unico che dovrebbe essere usato per chi sceglie questo formato. Tutto ciò, ovviamente, se stiamo parlando di rispetto degli standard, che è una cosa invocata da anni dai detrattori del solito nemico dell’umanità.
Infine l’esempio di JPEG e JPEG 2000 è perfettamente calzante perché la situazione è la stessa: il primo è il più supportato ed è, attualmente, l’UNICO standard. Il secondo dev’essere ancora standardizzato e non è supportato da tutte le implementazioni.
Di fatto, chi volesse scegliere di abbracciare quante più implementazioni possibile, dovrebbe optare esclusivamente per la versione 1.0.
@Nessuno: non credo tu abbia letto l’articolo, perché ti saresti conto che, al pari di tutti gli altri, Microsoft ha seguito fedelmente lo standard. Se sostieni il contrario, sei pregato di farmi vedere quale punto o punti del documento ISO avrebbe “violato”.
Per quanto riguarda la questione Java & co., ne abbiamo parlato abbondantemente nei commenti di questo http://www.appuntidigitali.it/8665/ie9-il-riscatto-di-microsoft-nel-panorama-dei-browser/ articolo.
Sulle differenze dei formati Office, mi sembra normale che per far fronte a nuove esigenze vengano aggiunti nuovi elementi. D’altra parte mi sembra che OpenOffice non sia fermo alla versione 1.0, ma a questo punto mi dirai tu come mai hanno deciso di supportare la 1.2; anzi, sarebbe interessante sapere per quale motivo hanno aggiunto altra roba quando c’era già il formato 1.0.
Per fare un esempio in un altro campo, a questo punto mi aspetto che se prendo un database realizzato con MySQL 1.0, l’ultima versione di quest’ultimo debba essere perfettamente in grado di leggerlo e scriverlo; e viceversa, ovviamente. Sempre secondo le tue “tesi”.
Anche per quanto riguarda il formato dei file di Office sei male informato, perché è disponibile DA ANNI la documentazione completa di essi. Ho scritto un articolo in proposito che stranamente ti sarà sfuggito, dove e sono presenti anche i link.
Sull’HTML, beh, qui c’è da sottolineare che Microsoft è stata la prima a supportare i CSS. Inoltre quando parli di lock-in potresti cortesemente esprimere la tua opinione sull’introduzione di frame da parte di Netscape; funzionalità che, ti ricordo, prima di allora non esisteva nemmeno nelle bozze del formato HTML 3.2. Idem per JavaScript, realizzato anch’esso dalla stessa casa e ovviamente assolutamente non standard all’epoca.
Sulla fantasiosa tesi della presunta corruzione della commissione ODF da parte di Microsoft mi sono già espresso prima. T’invito a farti un giretto sul web e vedrai che non aveva alcuna possibilità di farlo; anzi, sono stati segate alcune sue proposte. Ma è tutto messo nero su bianco.
La verità è quella che ho esposto nell’articolo: questo standard è stato realizzato coi piedi, da persone che ritengo del tutto incompetenti, e che hanno lasciato delle macroscopiche falle di cui stentavo a credere ai miei occhi quando ho letto tutto.
Quindi se di “colpe” vogliamo parlare possiamo farlo, ma è evidente che siano esclusivamente a carico di questi dilettanti che si sono dati la zappa sui piedi.
Comunque nell’articolo ho messo a disposizione il link allo standard: chiunque può visionarlo e rendersi conto personalmente di quello che ho scritto, e se ho riportato delle informazioni errate siete liberissimi di sbandierarlo ai quattro venti ed espormi alla pubblica gogna.
Non voglio certo ripercorrere 30 anni di storia dell’evoluzione su cui si è discusso in lungo e in largo per anni.
Comunque questa tua posizione sembra una difesa accesa ai comportamenti di MS. Comportamenti che per anni hanno prodotto gravi danni al mondo informatico limitandone la gusta evoluzione. Poi ognuno ha le sue idee, ma voler sempre trovare il lato giusto delle cose per non si sa quale motivo non fa bene a nessuno.
Solo sulla questione dell’introduzione delle nuove feature nei browser, non è che fosse mai stato vietato di fare cose nuove (che non esistendo prima non possono essere uno standard), ma quantomeno quello di riprendere quello che è stato fatto dagli altri e farlo in maniera uguale (se l’intento fosse stato quello di far del bene la mercato tutto, si intende). MS non lo faceva, tanto che si è dovuto inventarsi un modo per capire quale fosse il browser in uso per adattare il codice (tramite Java script) alle micromodifiche che MS ha sempre introdotto (tipo gli spazi vuoti tra una cella e l’altra che NESSUN altro browser faceva).
D’altronde MS non ha creduto in Internet fino a quando Netscape le ha dimostrato quanto antiquata (e anarchica) fosse la visione del mondo informatico da parte di MS che si è dovuta rimboccare le maniche e recuperare come poteva (cioè customizzando tutto il possibile) il terreno perso. Hai dimenticato di far riferimento agli ActiveX, tecnologia certamente portabile e sfruttabile da tutti gli internauti, vero?
L’articolo riguardo al formato dei file di Office mi è proprio sfuggito, ma che io ricordi ai tempi in cui MS era stata portata davanti ai banchi dell’antitrust questo era il nodo cruciale da dirimere a cui ovviamente MS (nella persona dello stesso Bill Gates) si era opposta dicendo che non poteva certo ddivulgare gratuitamente al mondo intero la propria tecnologia (chissà che ci sarà di così tecnologico in un banalissimo formato di salvataggio).
Della Java VM modificata ad hoc per il lock-in non c’è molto che
puoi dire, come infatti hai fatto. Il link riportato non parla di Java e delle manovre atte a cancellare l’oltraggio di Sun che aveva realizzato qualcosa che permettesse di eseguire lo stesso binario su qualsiasi piattaforma). D’altronde il risultato di quella sconfitta si chiama C# e .NET.
Per i CSS supportati da MS, ti quoto questa semplice frase da wikipedia: “Different browsers will render CSS layout differently as a result of browser bugs or lack of support for CSS features. For example Microsoft Internet Explorer, whose older versions, such as IE 6.0, implemented many CSS 2.0 properties in its own, incompatible way, misinterpreted a significant number of important properties, such as width, height, and float…”
Ma guarda un po’… le cose sono 2: o non sanno programmare a Redmond o hanno strategie diverse da quella che perseguono i creatori di standard.
Probabilmente, come ho detto, non sarà possibile determinare se la stesura dello standard ODF sia stata “manovrata” da MS (e probabilmente no, di incompetenti è pieno il mondo senza che MS ci metta del suo), ma per l’approvazione dello standard OOXML esistono chiari segni che MS è intervenuta per “aiutare” il processo di standardizzazione. Poi mi piacerebbe sapere perchè sarebbe dovuto nascere un nuovo “standard” quando ce n’era già uno esistente che copriva le stesse necessità. Forse perchè quest’ultimo non è libero da licenze da parte di colui che l’ha creato?
Suvvia, possiamo fare tutta la disamina che si vuole sui comportamenti di MS ma se uno non ha le fette di salame sugli occhi non può non vedere che vi è un fattore comune che è rompere gli standard (come giocare a scopa e puntare a spaiare le carte) o approfittare degli stessi. Se uno non è accorto (o non conosce le strategie del gioco della scopa) non lo nota nemmeno e sembra che qualsiasi cosa sia giustificabile fintanto che le regole del gioco sono rispettate (sìsì, lo standard ODF ha delle falle come detto e infatti MS prevedibilmente ci si è incuneata come un razzo, rispettando le regole). Ma da qualcuno che segue il mondo dell’informatica da anni mi aspetterei che questa politica fosse abbastanza chiara e invece di uscirsene con un articolo chiaramente a difesa del monopolista del mercato avesse provveduto a dare una migliore visione di quello che sono le strategie di una azienda che campa di standard proprietari dato che è evidente che della qualità delle proprie applicazioni non può certo fare affidamento.
Poi ognuno può rimanere della propria idea riguardo al caso specifico, ma se non si apre l’orizzonte temporale queste quisquiglie riguardo alle falle di una documentazione precaria lasciano il tempo che trovano.
Uno per tutti, se il documento dello standard ODF è stato redatto da incompetenti, per quello OOXML guardate qui, soprattutto la sezione intitolata “Reactions to standardization”:
http://en.wikipedia.org/wiki/Standardization_of_Office_Open_XML
Evidentemente c’è una certa differenza di esperienza nel trattare questi argomenti da parte di MS.
spero che non tocchino MS e che mandino a quel paese l’ISO..
sto tanto bene con office senza casini.. l’implementazione andava fatta a rovescio.. c’era uno standard de facto e quello andava preso..
ma per far sopravvivere anche gli altri si è inventati sto casino..
bella storia.. cmq uno standard aperto è prettamente un casino.. basta vedere quandi standard perdono anni per essere ratificati lasciando tutti nelle peste fino all’ultimo.. vedi i cavi HDMI.. HTML.. ODF.. aperti o no sono incasinati.. usuiamo quelli che ci sono e basta.. la guerra fra standard (HD-DVD vs BLURAY) ha sono creato clienti con oggetti inutili in casa.. spero che odf non faccia lo stesso.. io nel dubbio resto con office che da 15 anni mi ha servito bene..
@Nessuno: mi tocca quotarti questa volta.
Credo che tu non abbia letto bene l’inizio dell’articolo, dove spiegavo perché l’ho scritto.
Che il suo renderer HTML abbia avuto diversi bug è cosa nota. Comunque li ha corretti col tempo.
Netscape, invece, è stata tranquilla e attenta a rispettare gli standard, vero?
Ecco qui: http://en.wikipedia.org/wiki/Activex
E’ una tecnologia che ha introdotto Microsoft parecchio tempo fa, e di cui hanno fatto uso i suoi programmi e tanti altri. IE è soltanto uno dei tanti ad averlo usato (principalmente per gli update e per roba come Flash).
Ricordi male, appunto, perché nel caso che hai citato si trattava di Samba.
Mi sembra anche normale: visto che Java era di dominio assoluto Sun, Microsoft ha deciso di realizzare un progetto alternativo e decisamente migliore per superarne i limiti.
.NET è un ottimo progetto, con idee molto interessanti.
Questo: “Although the CSS1 specification was completed in 1996 and Microsoft’s Internet Explorer 3 was released in that year featuring some limited support for CSS, it would be more than three years before any web browser achieved near-full implementation of the specification. Internet Explorer 5.0 for the Macintosh, shipped in March 2000, was the first browser to have full (better than 99 percent) CSS1 support[citation needed], surpassing Opera, which had been the leader since its introduction of CSS support 15 months earlier.” hai dimenticato di citarlo però.
E, soprattutto, il seguito: “As of July 2008, no (finished) browser has fully implemented CSS2”
2008. Praticamente “ieri”. Su questo cos’hai da dire?
Inoltre: “Even though early browsers such as Internet Explorer 3 and 4, and Netscape 4.x had support for CSS, it was typically incomplete and afflicted with serious bugs.”
Leggi bene: IE e NetScape. Entrambi bacati. Però, “stranamente”, danno fastidio soltanto i bug del primo. Chissà perché…
Ma la chicca viene dopo. Ecco qui: “Problems with browsers’ patchy adoption of CSS along with errata in the original specification led the W3C to revise the CSS2 standard into CSS2.1” e “CSS2.1 became a Candidate Recommendation on February 25, 2004, but CSS2.1 was pulled back to Working Draft status on June 13, 2005,[3] and only returned to Candidate Recommendation status on July 19, 2007.”
Ricapitolando, anche il W3C coi CSS2 ha tirato fuori uno standard errato, ed è stato costretto a rimetterci mano con la 2.1, che è arrivata soltanto nel 2007.
Bene, hai presente quando è stato introdotto IE6? I conti fatteli tu, e traine le tue conclusioni…
A quanto pare chi crea gli standard continua a fare errori madornali. Inoltre Microsoft non era l’unica ad avere bug nel suo rendere HTML, e abbiamo dovuto aspettare il 2008 per vedere un browser completamente compatibile con lo standard.
Direi che la cosa si commenta da sé…
Comunque preferirei continuare a commentare soltanto l’oggetto del presente articolo.
Era nel suo interesse, visto che aveva già sviluppato un prodotto. L’importante è che lo standard sia consistente e non bacato.
Dove sta scritto che non se ne possano creare altri? Non mi pare che ISO & compagnia pongano limiti al numero di standard per specifici settori.
A me risulta che sia completamente libero. Hai delle prove a supporto di questa tesi?
Ma poi non mi pare che JPEG, MP3, MPEG, H.264, ecc. sia esenti da brevetti e/o licenze pendenti, ma qui, “stranamente”, si chiude un occhio…
Come ho detto all’inizio, ho scritto quest’articolo a causa di un intervento di un utente (in un altro precedente) per sfatare la classica leggenda metropolitana che circola e che era del tutto falsa e infondata.
E tu come ti classifichi, visto che tiri in ballo monopoli che non esistono, standard proprietari quando non ve n’è l’ombra, e fai affermazioni sulla qualità di certe applicazioni senza alcun fondamento tecnico? Non mi pare che così si vada lontano.
Comunque che Microsoft faccia i propri interessi mi sembra scontato. D’altra parte lo fanno anche le altre aziende, pure quelle che vengono spacciate come paladine protettrici di open source, standard aperti, et similia.
Solo che dà fastidio soltanto lei. Al solito…
Mi spiace, ma qui le idee non sono in discussione: lo standard ODF è DIMOSTRATO presentare gravissime falle che ne minano l’interoperabilità.
A parte le patetiche schiere di invasati che manifestano adducendo slogan da telebani informatici, non capisco cos’altro avrei dovuto vedere dal link che mi hai passato.
Non riesco a capire la logica che sta alla base della descrizione di un formato, utilizzando una lingua “parlata”.
Visto e considerato che una frase può essere poco chiara, mal interpretata, posta su “piani d’importanza” diversi a seconda di dove viene posizionata (quanti si leggono per intero un testo e non cercano di trarre conclusioni dalle prime pagine che teoricamente dovrebbero contenere il sunto del discorso) perchè ci si ostina ad utilizzare parole e frasi dove il senso può essere puntualmente frainteso ?
Non si farebbe molto prima a fare solo una sfilza di esempi fornendo rigidamente le sintassi da utilizzare ?
E’ un po’ come con i contratti: mettendo da parte il punto che si sa perchè sono sempre lunghi, contorti e scritti in piccolo (fregare chi cerca di leggerlo) non si farebbe molto prima a fare disegnini e freccette ?
Guardiamo le pitture rupestri degli uomini preistorici e ci immaginiamo delle bestie incapaci di comunicare in maniera complessa, ma signori, quelli erano dei geni: avevano capito tutto.
Una comunicazione logica semplice, trasmette chiaramente il messaggio senza perdersi dietro sottigliezze che a seconda del vocabolario utilizzato assumono questo o quel significato.
Per fortuna che questi draft vengono ancora scritti in inglese e non italiano: ci vorrebbe l’accademia della crusca ogni volta per capire dove l’autore voleva andare a parare.
Riguardo alla storia del formato zip, sorvolo pietosamente.
Al contrario, l’italiano come lingua avrebbe meno ambiguità e sarebbe più utile nella definizione degli standard. Se non ricordo male all’ONU per questioni molto delicate si preferisce comunicare in francese anziché in inglese proprio per questo motivo.
Comunque nel draft dello standard ODF di esempi ce ne sono parecchi. Il problema sta nelle parole utilizzate, che sono del tutto sbagliate in quei precisi contesti.
In ogni caso non è che ci voglia molto a scrivere un documento che definisca tutto per bene: è questione di saperci fare. Prendi il draft di JPEG o JPEG 2000 e vedi un po’ se ci sono macroscopiche mancanze come nel caso dell’ODF.
Il problema, insomma, rimane sempre l’essere umano.
Non per fare facili battute di bassa lega ma a Napoli dicono che il Semaforo Rosso non trasmette un obbligo ma un consiglio.
Il problema è la gente oltre che la lingua. Ci vorrebbe un linguaggio dal numero di vocaboli limitato dove le parole sono bianche o nere, senza zone di grigio all’interno delle quali stupidità, convinzioni errate e furbate atte a creare deviazioni d’ incompatibilità possano avere vita facile.
Ci vorrebbe anche un sistema di controllo capace di multare pesantemente chi si permette di sgarrare al di fuori dei binari fissati dallo standard ma questo solo in seguito quando effettivamente non ci sono draft terribilmente lunghi che si prestano più a libere interpretazioni che non a ben precisi punti.
soprattutto, ci vorrebbe uno standard che sia uno e definitivo senza revisioni a poca distanza di tempo dalla versione iniziale – che a maggior ragione nel caso specifico dei formati per documenti d’ ufficio (materia assai “semplice” se rapportata ad altre applicazioni informatiche, ma soprattutto, quasi immutati rispetto agli anni 90 (nell’ ultimo decennio è cambiato il modo di salvare il data model su disco – passando da un efficiente formato binario a del markup compresso a cui mi sto ancora chiedendo chi abbia avuto la brillante idea di pensare – sono cambiate le applicazioni che lo editano, divenute più flessibili e comode da usare… ma il data model stesso, le singole feature che concorrono a definire lo stato del documento e che devono essere persistite su disco, quindi ciò che deve essere previsto a livello di formato, non è cambiato granchè – sempre di testo impaginato in pragrafi con immagini e tabelle, o di spreadsheet con testo e formule si tratta) poteva -e avrebbe dovuto- essere studiata, ufficializzata e non più toccata
ODF avrebbe dovuto fermarsi ad una 1.0 completa di tutte le caratteristiche richieste nello scenario aziendale di questo inizio di millennio – eventualmente costituire un superset (piuttosto che un minimo denominatore comune) di ciò che singole società o progetti possono arrivare a supportare, e tenere conto delle diversità risultanti a livello di “copertura”, con un sistema di “profili” e di fallback previsti a livello di standard e obbligati a livello delle applicazioni …) – un approccio del genere avrebbe probabilmente permesso di creare uno standard più robusto e soprattutto durevole
le basi c’ erano (partendo da zero e usando un linguaggio di markup divenuto la piaga del mondo informatico), le possibilità c’ erano, ma non ce n’è stata evidentemente la capacità (per fare uscire una versione 1.1 e una 1.2 vuol dire che nella 1.0 si è lasciato fuori qualcosa che avrebbe potuto essere previsto -anche in prospettiva futura- quindi l’ analisi dei requisiti è stata carente), il coraggio, o la volontà (per molti, un qualcosa di fermo alla versione 1.0 è automaticamente obsoleto, il “rev up” è “necessario” per dare un’ illusione di progresso e innovazione)
o forse, semplicemente, è la riprova del fatto che che il design by committee raramente funziona…
“ci vorrebbe uno standard che sia uno e definitivo”
Questa è una piaga che il mondo open source si porta dietro fin dagli inizi
Ultima risposta:
Cesare, non confondere “bug” con “interpretazione volontariamente errata”. Se MS avesse considerato com BUG tutti i problemi del proprio render HTML avrebbe fatto delle patch, tra le centinaia che distribuisce tutti i mesi, per risolvere i problemi.
Invece IE6 è, da quando è uscito, un browser che fa quello che vuole delle regole.
Onire a MS che ha inserito per prima il supporto ai CSS, ma purtroppo, come si vede, l’interpretazione dello stesso è stato sempre afflitto da “bug”.
Di Opera puoi dire tutto, ma sicuramente lì gli standard sono considerati e i bug, quelli veri, sono normalmente risolti con le versioni successive. Opera browser sono anni (non giorni) che ha un punteggio del 100% all’ACID test. MS non si è mai avvicinata a tale cifra con nessuno dei prorpi browser. E solo dopo l’accusa di Opera alla commissione europea IE ha tentato di sistemare le cose.
Poi, questa cosa che MS è sempre quella martellata dall’opinione pubblica… sinceramente ancora una volta speravo meglio da parte di un utente esperto e navigato del mondo dell’informatica. MS non è una società cantinara che può o non può permettersi di essere rispettosa del mercato perchè deve emergere in qualche modo. MS ha l’80% del mercato nel mondo office e quasi il 100% di quello degli OS. E’ ovvio, per chiunque non sia caduto dalla Luna ieri, che MS DEVE essere tenuta sotto controllo affinché il resto del mondo informatico non sia schiacciato dalle sue scelte liberticide. Scelte perpetrate sin dalla sua fondazione, ma oggi sono un pericolo per tutti.
Riguardo all’approvazione dello standard OOXML, tra gli invasati che pongono di riflettere su come MS si è comportata ci sono degli esponenti IBM ma anche la Commissione Europea. Ci si deve porre la questione del perché MS abbia fatto in modo che l’OOXML fosse lo standard approvato più velocemente della storia degli standard quando poco tempo prima ne era stato creato uno del tutto simile per le stesse funzionalità. Innovare è lecito, ma i modi in cui queste cose sono avvenute fanno accendere qualche lampadina.
Comunque continuo a non capire: sei un dipendente MS o ti paga in qualche modo per voler sempre girare la frittata a loro favore? Se vuoi possiamo anche discutere di come la MS si è difesa in tribunale contro la commissione antitrust americana e di come Bill Gates non ricordasse più di metà delle cose che gli venissero contestate o di come MA hs falsificato video per cercare di dimostrare con stavano assolutamente pensando a fregare la concorrenza con mezzi non leciti.
Ma sicuramente invasati come me non hanno il diritto di criticare le scelte politiche (non tecniche bada bene) di una azienda che da decenni rallenta tutto lo sviluppo informatico per “interesse legittimo”.
lo stesso ambito applicativo sì, le stesse funzionalità è difficle se non impossibile
il fatto stesso che ODF sia implementabile da suite tanto diverse (e in certi casi scarne di funzioni) come office (con plugin di importazione ed esportazione), openoffice, koffice, gnumeric/abiword, ecc, e il fatto che le specifiche OOXML siano estremamente più corpose (al punto che qualcuno ha detto che non sarebbero soddisfacibili se non riscrivendo office 2007, o comunque clonandone le funzionalità, per intero (*)) denota una notevole differenza di scope …
Ad Hominem + PaidMicrosoftShill(TM)
primo: non prendere il web come punto di riferimento tecnologico, il web è bassa ( molto bassa) tecnologia i nconfronto a praticamente ogni altra applicazione informatica o elettronica – volutamente, ed è giusto che sia così, altrimenti non potrebbe fare da vettore universale
secondo: detto ciò, tutto mi sembra meno che microsoft rallenti lo sviluppo tecnologico – al contrario, il numero e livello delle funzionalità introdotte in vista e seven dà l’ idea di un’ azienda che continua a premere sull’ acceleratore e a innovare -pur correndo praticamente da sola
terzo: non posso fare a meno di perplimermi (cit) per come da una parte si dia “colpa” a MS per il continuo aggiornamento dell’ HW, richiesto dai suoi sistemi operativi sempre più pesanti (quando questo, vero o no, è il motivo per cui adesso abbiamo sul mercato hw dalle prestazioni impensabili solo qualche anno fa a prezzi abbordabilissimi) e la si accusi di “rallentare lo sviluppo informatico”
delle due, l’ una…
@Nessuno:
Bug che riguardano anche gli altri, ma non è questo il punto. IE6 per il render HTML utilizza un apposito controllo ActiveX, a cui è delegata questa funzionalità.
Questo significa che anche altre applicazioni ne possono fare uso (e l’hanno fatto), e idem per i tool di creazione delle pagine web. Senza andare troppo per le lunghe, cambiare il codice del renderer avrebbe comportato ovviamente malfunzionamenti su tutto il lavoro già fatto (da questa gente) presupponendo il rendering fatto in un certo modo.
Per cui, a mio avviso, i bug fix intercorsi dalla commercializzazione di IE6 saranno stati per problemi di sicurezza, oppure per fix dell’interfaccia grafica di IE6 (questo non inficia il renderer). Per lo meno, io avrei fatto così, per tutelare chi si è affidato al mio componente.
Mi sembra anche normale. Come ho riportato prima, è stato lo stesso W3C ad ammettere che lo standard era ambiguo / non corretto, e la successiva versione coi fix è arrivata, ma soltanto nel 2007.
IE7, il successore di IE6, è arrivato l’anno prima, nel 2006. Quindi l’adeguamento allo standard è arrivato con la versione successiva, IE8, nel 2009, e infatti supporta pienamente lo standard HTML e relativo CSS 2.1.
Permettimi: Opera innanzitutto non ha un enorme bacino di utenza a cui dover dare conto. E seconda cosa, ma più importante, lo standard è arrivato soltanto nel 2007, come dicevo prima.
Ma guarda che sul fatto che sia tenuta sotto controllo io sono d’accordo. E’ sulle eventuali sanzioni che sono in disaccordo, fatta eccezione per le pratiche di concorrenza sleale (tipo accordi di esclusiva sottobanco per tagliare la concorrenza, per intenderci).
Sul resto non val la pena commentare (e comunque j ti ha risposto).
@Cesare
Non capisco questa difesa a spada tratta della condotta di MS.
Che le persone che hanno redatto quel documento siano degli ‘sciocchi’ (non me la sento di definirli incompetenti, ne sanno a pacchi piu’ di me, molto probabilmente) e’ innegabile.
Altrettanto innegabile e’ la malafede di MS che ha approfittato di queste leggerezze per mettere i classici bastoni fra le ruote.
Saluto
Come dicevo, tutto nasce dal commento di un utente a un articolo precedente.
Per cui ho voluto mettere le cose in chiaro.
Inoltre Microsoft ha avuto le sue ragioni per implementare le formule in un certo modo, come puoi leggere dall’articolo di Doug Mahugh.
Una risposta veloce a j
La questione ad hominem non si pone. Non ho dichiarato che la tesi qui descritta sia falsa. Ho solo detto che nella sua piccolezza è vera, ma se si amplia lo sguardo a orizzonti più ampi, la cosa assume tutto un altro significato.
La questione che la non ottimizzazione del SW seguita dalla richiesta continua di un incremento di prestazioni del PC per far girare le applicazioni MS sia \progresso\ o \evoluzione\ è davvero curiosa.
La tecnologia Web potrà anche essere \bassa tecnologia\ ma se MS ha problemi a implementarla in maniera corretta, ci si deve allora chiedere cosa bisogna aspettarsi dall’uso di tecnologia \più evoluta\.
@Cesare
Hai descritto perfettamente qual è il problema di MS. Il lock-in voluto o meno. Le azioni di MS sul mercato sono catastrofiche per questo. Avere un broswer alla sesta release che ha devastato lo sviluppo Web per bachi più o meno voluti è una cosa a mio parere gravissima. Anche l’antitrust lo aveva capito, peccato che le forze in gioco abbiano determinano un esito diverso da quello sperato.
Qui mi fermo perché credo sia inutile ribadire il mio punto di vista che mi sembra chiaro e in antitesi con quanto si cerca di dimostrare qui.
/edit: interessante il captcha… “formats defense” :D
I captcha non li vedo. :D
Comunque considera che se abbiamo roba come AJAX, su cui è ormai fondato il web ed è disponibile a tutti, lo dobbiamo proprio a Microsoft. ;)
Su IE6 e sue vicissitudini ho risposto in maniera puntuale. E non mi sembra che se di colpe dobbiamo parlare, queste siano esclusivamente a carico di MS. Sul W3C, ad esempio, non ti ho mai visto dire nulla, mentre a mio avviso ha le colpe maggiori.