Utilissimo l’esempio su OOXML, grazie davvero Stefano.
Su wikipedia ho trovato questo sintetico resoconto:
… the specification is currently undergoing fast-track standardization within the International Organization for Standardization (ISO) as DIS 29500 (Draft International Standard 29500), but the draft text has failed (as of the September 2007 ballot) to reach sufficient approval from ISO national body members to be accepted as a standard.
…
e qui il resoconto del ballot:
This has been observed to be perhaps the most controversial and unusual ISO ballot ever convened, both in number of comments in opposition, and in unusual actions during the voting process. Various factions have strongly supported and opposed this fast track process: primarily on one side Microsoft affiliated companies in support and on the opposing side free or open source software organizations, IBM and affiliates, SUN Microsystems, and Google.
Mi sembra dia bene l’idea di cosa a volte si può fare per impedire proprio “maneggi” stile Microsoft, agendo formalmente e all’interno di enti di standardizzazione.
(Per cronaca: l’Italia si è “astenuta”, cosa che capita spesso (purtroppo) anche per standard ISO19100.)
Mi chiedo: succederà qualcosa di simile anche con KML (Google>OGC>ISO) ??
Perché non ci sono grandi aziende che possono investire nello sviluppo di standard?
Posso però far notare che gli iscritti ad UNINFO sono passati da 5 a
oltre 80 nelle settimane precedenti al voto su OOXML.
Sicuramente scrivere o anche solo leggere standard non è entusiasmante, ma dovrebbe far parte del nostro lavoro, no?
Sull’investimento: non credo che qualche centinaio di euro all’anno possano essere un freno per un’azienda (anche media) o un’associazione (!).
Il problema, secondo me, non è economico ma culturale: tra gli attuali iscritti a UNINFO ci sono Politecnici, Istituti di ricerca, Enti pubblici; nonostante alcuni di questi siano “soci di diritto” (cioè non pagano) il loro contributo è pressochè nullo.
Perchè?
pg
Il 15/10/07, Stefano Maffulli <stef@maffulli.net> ha scritto:
On Mon, 2007-10-15 at 10:10 +0200, Piergiorgio Cipriano wrote:
Domanda1: a quali ti riferisci in particolare? Puoi fare qualche
esempio concreto (magari di standard 19100)?
Non ho esempi di standard ISO 19100 approvati ma coperti da brevetti, ma
ho seguito direttamente la vicenda della tentata approvazione in UNINFO
(e ISO, a livello internazionale) del non-standard Microsoft OfficeXML
(OOXML). Lì si è visto in modo chiaro quanto ISO sia vulnerabile
all’approvazione di formati e protocolli che non consentono alcuna
interoperabilità reale. Nel tempo ho raccolto un po’ di webografia al
riguardo:
http://del.icio.us/smaffulli/OOXML (segnalo gli articoli di Groklaw)
Domanda2: secondo te (voi) perchè in Italia pochissimi si prendono la
briga di partecipare attivamente all’attività ISO o CEN?
Ah, questa è una bella domanda cui posso solo rispondere con ipotesi:
perché scrivere uno standard è cosa complessa e noiosa? Perché non ci
sono grandi aziende che possono investire nello sviluppo di standard?
Posso però far notare che gli iscritti ad UNINFO sono passati da 5 a
oltre 80 nelle settimane precedenti al voto su OOXML.
Sarebbe molto utile una partecipazione più nutrita e costruttiva.
In modo da non limitarsi a dire “beh, questo standard così come lo
hanno scritto non è applicabile” ma piuttosto contribuire a “scrivere”
gli standard.
Che ne pensi (pensate)?
Penso che la partecipazione dovrebbe aumentare, ma anche la tutela
dell’interoperabilità dovrebbe essere garantita. Il W3C si è dotato di
una policy sui brevetti abbastanza chiara che garantisce l’uso
indiscriminato e gratuito per tutti i formati e protocolli
standardizzati dall’ente. Gli altri enti, ISO in primis, dovrebbero
imitare il W3C.
p.s.
Non ho letto tutto l’articolo che hai segnalato: perdonami, sono quasi
3mila parole, e nelle prime 1000 non ho trovato molta attinenza con il
tema delle informazioni geografiche.
Sarà che è lunedi mattina e che sono ancora abbastanza …ito!
Hai perfettamente ragione. Non riguarda le informazioni geografiche ma
l’interoperabilità in informatica:
Part of the explanation for the catastrophe was the sheer
complexity of the A380. The cabin wiring—more than 330 miles of
it and over 40,000 connectors in each aircraft—caused problems
because two incompatible versions of computer-aided design
software were used. The Germans in Hamburg had one system, the
French in Toulouse another. When the electrical harnesses came
to be fitted in the forward and aft fuselage sections, many
didn’t connect with each other. Despite efforts to resolve this,
it was decided in October last year that only by updating the
computer-design tools would Airbus get on top of the problem.
That meant a third delay.
È simile alla storia del satellite sparato oltre Marte per un errore di
conversione da sistema strampalato a sistema metrico.
cheers
stef
–
Piergiorgio Cipriano
pg.cipriano@gmail.com
http://www.freegis-italia.org