people as middleware
Evviva l’interoperabilità!
ISO ha rilasciato il comunicato stampa ieri, ci siamo: ISO/IEC DIS 29500 meglio conosciuto con il nome di OpenXML è diventato IS 29500, quindi standard de jure. Pochi mesi fa la situazione non era molto chiara, anzi fino allo scorso BRM tenutosi a Ginevra molti National Body, compresa l’Italia erano ancora indecisi sulla conferma/ritrattazione del proprio voto. Il periodo subito dopo il BRM, 30 giorni, è stato decisivo per rivedere la nuova posizione dello standard proposal promosso da ECMA e alla fine, questo ha convinto i più dando la possibilità ad OpenXML di affermarsi *as standard*. Personalmente, come mebro italiano della commissione UNINFO sono molto soddisfatto del lavoro che abbiamo svolto in commissione e ringrazio tutti i partecipanti alle varie assemblee per aver dato, in molti casi, il meglio di loro *in tutti i sensi*. Ora ha inizio la vera fase di lavoro, almeno per me: una fase in cui tutti dovranno impeganrsi per far si che tra almeno due anni ci sia una definizione omnicomprensiva delle esigenze linguistiche, funzionali e di veicolazione del dato che non facciano più utilizzo dei vecchi formati documentali. Questa è la vera sfida, penso a quando verrà il momento di esaminare UOF e far fronte alle esigenze proprie dell’informazione universale. Buon lavoro!
| Print article | This entry was posted by rp on April 2, 2008 at 4:30 pm, and is filed under about. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site. |
about 2 years ago
Una domanda: visto che lo standard secondo me ha dei punti oscuri, non pienamente definiti, si procederà alla loro revisione oppure verranno mantenuti così rendendo di fatto lo standard non usabile al 100%?
about 2 years ago
Ciao FDG, considera che lo standard che è *passato* è molto diverso da quello inzialmente proposta da ECMA. Personalmente i miei dubbi sulle questioni tecniche per me *non ammissibili* sono state chiarite, come ad esempio la questione delle date, la questione degli abusi dei vari *shell, may, ecc.* e non ultimo le questioni relative alla *compliant* del formato elettronico dei file schema nei confronti di quello cartaceo. Riguardo al futuro, come ho scritto nel post, penso che sia giusto nell’arco di due anni procedere ad una riunificazione dei nuovi formati xml-based per far si di comprendere esigenze diverse legate alla globalizzazione e alla digitalizzazioned elle informazioni. Non sono d’accordo sul fatto che ODF e OXML non sono/saranno utilizzabili, quali sono i tuoi dubbi?
about 2 years ago
Intanto ne approfitto per esprimere un mio pensiero in proposito. Io vedo questo come uno standard che documenta l’esistente, quindi utile per poter accedere ad un’enorme mole di documenti che possono essere resi disponibili attraverso il formato openxml. Però non mi pare uno standard ben congegnato per decidere di adottarlo come formato per il domani. Ci sono una serie di ragioni che mi spingono a pensare ciò. Intanto, si è fatto poco per riciclare, conoscenze, formati, codice (certo non le attuali implementazioni di openxml). Poi ci sono altre considerazioni, tipo ammettere comportamenti errati nello standard, che sono “discutibili”. Tutto ciò può andarmi bene se questo serve rendere possibile accedere all’esistente. Tuttavia, nonostante il processo di revisione degli ultimi mesi, mi pare che ci siano dei problemi non risolti. Mi limito ad un solo esempio, che per me ha una certa rilevanza: il linguaggio macro. Ok, ci possono essere ragioni formalmente corrette per non includere nella specifica le macro, ma dal punto di vista pratico per me questo è limitante ed anche potenziale fonte di problemi.
about 2 years ago
Riflessione condivisibile in parte. Automatismi come le macro è giusto non includerle nel core di uno standard documentale, in qaunto appuinto sono *automatismi* che riguardano la parte applicativa. Microsoft Office 2007 supporta la retocompatibilità ma stai pur certo che uno standard documentale non deve permettere la generazione di macro se non supportato a livello applicativo. Quindi ben venga l’automazione ma non deve appartenere al nucleo minimo di specifiche dello standard. Ultimamente risvolti molto seri di utilizzi delle macro, per fare un esempio, hanno impatti seri anche sul mondo della firma digitale: che cosa succede se un utente firma un qualsiasi documento che al suo interno contiene un campo calcolato che tra 20 anni conterrà un valore del tutto diverso? Alla sua ruapertura la firma digitale non potrà più essere valida! Ora la questione è: chi deve preoccuparsi di impedire l’inserimento di automatismi all’interno dei documenti? Il formato o l’applicazione di firma digitale? Ecco questo, credo sia un problema comune a molti che spero ci faccia coinvolgere tutti verso una soluzione comune e cioè quella di permettere l’inserimento di automatismi o funzioni di retroconmpatibilità solamente a livello di applicazione, chiamiamola anche intraoperabilità, ma queste funzionalita non devono e non dovranno appartenere nativamente ad uno standard documentale di nuova concezione.
about 2 years ago
Beh, ammesso che sia condivisibile il tuo ragionamento (si tratta di problemi superabili se si accetta di spenderci il tempo necessario ad affrontarli), di fatto è un’interoperabilità ristretta rispetto al reale uso del formato.
about 2 years ago
Questo post è stato aggregato su NonSoloZapatero.it l’aggregatore del web sociale e socialista.