Microsoft e i formati Open di Office

Paradossalmente l'utenza non ha spesso la competenza necessaria per stabilire cosa sia meglio per se stessa, ne' tantomeno questo può essere stabilito da un produttore il cui unico interesse è il banale profitto economico. Per questo enti di standardizzazione indipendenti come il W3C sono solo un toccasana... ovviamente serve poi un pool di produttori (Mozilla Foundation?) che dia adito a queste cose, altrimenti rimane una cosa fine a se stessa.

purtroppo chi non programma, e/o chi vede i componenti sia SW che HW come scatole chiuse dall' oscuro funzionamento, non sarà portato a pensare a come può essere strutturata una soluzione (prodotto) SW, ma ne vede più che altro le implicazioni sociopolitiche o di marketing, a maggior ragione quando si subisce un condizionamento così radicale come quello operato dai media...
e a maggior ragione quando si parla di formati di file in un momento in cui la parola d' ordine sembra essere "Interoperabilità e Leggibilità umana"... anche se questa sembra tutta prima sembra antitetica rispetto al richiedere efficienza e completezza dal programma chiamato ad aprire i documenti stessi

quindi se i programmatori usano un determinato formato binario non è perchè si avvicina di più ad un dump delle strutture dati allocate in memoria, ma perchè sono "cattivi"...

bella questa ! ... devo segnarmela da qualche parte ...

cmq mi ha incuriosito il tuo riferimento ai "media"... non mi sembra che "interoperabilità e leggibilità umana", formati di documento, strutture dati in memoria e tecniche per la loro persistenza, etc. sianop argomenti molto popolari...

Può benissimo succedere, perché questo nuovo formato potrebbe rendere impossibile la perfetta conversione dei documenti di Office, oppure "castrarne" dei dettagli (pur importandoli). Faccio un paio di esempi per chiarire.

Nel primo caso, supponiamo che abbia realizzato un programma di modellazione 3D che fa uso di solidi di rotazione per rappresentare gli oggetti più semplici, e che questi possono poi essere "combinati" con operazioni booleane "classiche" (and, or, not, xor) per formare gli oggetti più complessi.
Capisci bene che sarà impossibile poter conservare queste informazioni se i formati standard che dovrò usare mi permettono di memorizzare soltanto punti, linee, triangoli, ecc.

Per il secondo caso supponiamo che il nuovo formato non preveda la definizione della filigrana. Quindi convertendo un documento che la contiene, succede che l'immagine da appioppare sullo sfondo del documento viene importata correttamente, ma se ne perde il "significato": sarà un'immagine come qualunque altra e trattata allo stesso modo.
In soldoni: non potrò più utilizzare le facilitazioni che i programmi che prevedono questo tipo di oggetto mettono a disposizione. L'utente perde un valido strumento di lavoro, insomma: può ancora ottenere ciò che vuole, ma non allo stesso modo (cambia completamente l'approccio, e soprattutto perderà molto più tempo rispetto a prima).

Questo per chiarire ulteriormente la questione, anche se EvilBoy prima e jappilas più approfonditamente dopo hanno evidenziato quale potrebbero essere i problemi.

Oltre a ciò, c'è da sottolineare che quando si parla di formati, spesso si tende a bollare quelli di MS perché sono "proprietari", "chiusi" e sui quali gravano brevetti e licenze, e quindi che "soffocano" il mercato la concorrenza.
Vorrei ricordare che siamo STRAPIENI di formati "proprietari", "chiusi" e sui quali gravano brevetti e licenze, ma che "passano in cavalleria" soltanto perché non c'è scritto MS accanto a loro...

Per il fatto dell'open document che sta stretto a MS vorrei prima un documento tecnico che ne spiegasse le ragioni, poi ci posso anche credere.

Per i formati chiusi guarda che sono pienamente d'accordo, fosse per me metterei solo formati open e free per qualsiasi cosa.
Alla fine io credo che se un documento/file lo puoi leggere ovunque nel mondo e con qualsiasi programma sia un vantaggio non uno svantaggio, sia per l'utente che per il produttore di SW, free o non-free che sia.

Se MS (e tutti quelli che producono standard chiusi o non-free) avessero meno quote di mercato vedrai come si adeguerebbero agli altri standard anche open.

Mi pare stranamente diffusa l'idea che in fatto di standard le aziende devono poter fare tutto ciò che gli pare senza dare alcun peso all'interoperabilità (o magari sono io che interpreto male, ditemi voi). Francamente io apprezzo il fatto che, anche se a casa mia le prese di corrente sono BTicino, possa attaccarci apparecchi Candy oppure Electrolux e sia tranquillo che la corrente mi arrivi a 220V, e che l'installazione me la possa fare Pinco Pallo, anzichè l'elettricista BTicino. Mi rompe andare all'estero e dover ricorrere ad adattatori vari per usare i miei apparecchi. In questo campo gli organismi internazionali sono indubbiamente in ritardo (UE per prima), ma non mi pare che l'iniziativa privata abbia supplito in alcun modo.

Sì, ma non molte aziende hanno esplicitamente espresso l'intenzione di utilizzare i loro formati proprietari per estendere il proprio monopolio. Vedi discussione precedente.
Mi dispiace vedere bollati come "pregiudizi" delle opinioni che vengono espresse assolutamente a posteriori di certi comportamenti. Se ti ho visto rubare, poi sono prevenuto se non ti credo quando mi dici "poi te lo restituisco"?

Io SONO un programmatore e mi permetto di dire solo una cosa: se per salvare un documento si fa un dump della memoria allora siamo veramente mal messi.

Così un qualunque baco/difetto/errore nel documento te lo porti avanti finchè il documento vive, con il rischio che si propaghi e corrompa il documento in modo definitivo.

E poi sempre che venga salvato un dump, sarebbe questo il formato open di microsoft?
Dubito che in RAM si tenga una descrizione così "chiara" del documento.

Nel momento poi in cui lo devi salvare e quindi creare un file che descriva il documento, non penso che faccia molta differenza a usare un formato anzichè un altro, si tratta in ogni caso di scrivere un routine che componga l'output a partire da quello che è in memoria.

E non credo assolutamente che in microsoft manchino le risorse per implementare l'ODF. Semplicemente è stato deciso di NON implementarlo. Mi ci gioco le OO che è stata una pura scelta di marketing e non tecnica.. Speriamo solo che rimanga veramente open e royalty free (non ricordo di preciso, ma mi pare che non molto tempo fa microsoft abbia registrato qualche brevetto inerente alla conversione di strutture dati in file XML o roba del genere... chissà se c'è qualche legame tra le due cose)

EDIT:
Ecco un link dove si parla del brevetto:
http://punto-informatico.it/p.asp?i=53190&r=PI

Concordo pienamente: primo quel brevetto (come molti altri) non doveva essere mai stato rilasciato e secondo finche' non vedo scritte le ragioni tecniche per la mancata adozione di OpenDocument continuero' a credere che MS l'ha fatto solo perche' ha sempre rinnegato tutti gli standard che non sono suoi.

invece con il formato XML based si parte dal presupposto che l' applicazione sia intrinsecamente fallata e commetta, in fase di salvataggio o importazione, errori da correggere a mano...

più o meno la differenza tra un linguaggio di alto livello e una rappresentazione bytecode
esempio fittizio: devo progettare e scrivere un programma, che prendendo degli script testuali anche molto lunghi, li interpreti ed esegua ripetutamente le operazioni matematiche ivi descritte... secondo te:
farò ogni volta il parsing delle stringhe per estrarre i singoli elementi simbolici (tokenizzazione) e dalla lista di simboli funzionali noti, recuperare l' indirizzo di memoria a cui si trova la funzione,
oppure lo farò una sola volta per sostituire ad ogni token un "ID" di lunghezza fissa (ID che conoscerò in quanto scrivo io la tabella delle funzioni) in modo che il reparsing sia costituito dal fetching di un solo BYTE o coppia di BYTE, alla volta invece di tutta una stringa, e quel byte contiene già l' offset della tabella di puntatori a funzione? )

nel primo caso lavorerei sempre su un testo in chiaro, quindi umanamente leggibile e correggibile, e forse lo svilupperei in meno tempo usando solo un parser regula expression... ma questo vantaggio sarebe compensato da una minore efficienza in fase di esecuzione
nel secondo lo sviluppo sarebbe leggermente più complicato perchè dovrei prevedere sia il parser e relativa macchina a stati basata su bytecode, sia l' uso del parser e tokenizer REGEX (non necessario se lavoro soltanto col bytecode), perderei la leggibilità umana della versione bytecoded del mio script o della mia struttura dati, ma risparmierei tot cicli di clock per ogni token , con un vantaggio finale non trascurabile

per me, è più "marketing" il contrario...
o meglio, in un' azienda di produzione di SW, a parte il marketing che è rivolto all' esterno, esiste la figura del "client", una o più persone che, pur non avendo conoscenze tecniche, dicono al reparto tecnico cosa si vuole che il prodotto finale faccia o come si vuole che appaia all' utente e così via
la prima impressione è che per un certo numero di versioni sia stata data carta bianca al reparto tecnico per quanto riguardava il formato di salvataggio, dando la priorità all' applicazione stessa (che la richiesta cioè, fosse di realizzare un prodotto che fosse efficiente e stabile pur soddisfacendo i requisiti funzionali , che evidentemente non prevedevano che l' utente dovesse mettere le mani nel file generato)
e che la funzione di salvare in un formato xml based (quindi human readable - anzi, proprio perchè human readable -e quindi non "nativo" per la macchina, quindi intrinsecamente meno efficiente di un formato binario) sia un qualcosa che il "client" ha aggiunto alla TODO list solo in tempi recenti, magari per assecondare quella che appariva come la nuova moda... "XML è lo standard del futuro! Sun salva in XML, dobbiamo farlo anche noi!"