/docs/ “canon digital”: una evaluación crítica

Nº 182, julio-agosto 2006, año XXXIINº 182, julio-agosto 2006, año XXXII

Revista de la Asociaciónde Técnicos de Informática

Formato de Documento Abierto(ODF)

Nº 184, noviembre-diciembre 2006, año XXXII

Nº 184, noviembr Nº 184, noviembr Nº 184, noviembr Nº 184, noviembr Nº 184, noviembre-diciembre-diciembre-diciembre-diciembre-diciembre 2006, año XXXIIe 2006, año XXXIIe 2006, año XXXIIe 2006, año XXXIIe 2006, año XXXII

Monografía del próximo número: "Buscadores en la Web"

editorialLa enseñanza de la Informática en España > 02en resumenUn estándar, dos estándares > 02Llorenç Pagés Casasnoticias IFIPActividades del IFIP TC6 Technical Committee on Communication Networks > 03Ramón Puigjaner Trepat

monografíaFormato de Documento Abierto (ODF)(En colaboración con UPUPUPUPUPGRADE)Editores invitados: Jesús Tramullas Saz, Piedad Garrido Picazo, Marco FiorettiPresentación: OpenDocument, estándar para documentos digitales > 04Jesús Tramullas Saz, Piedad Garrido PicazoAbierto desde el diseño: el Formato de Documento Abiertopara aplicaciones ofimáticas > 06Erwin Tenhumberg, Donald Harbison, Rob Weir¿Es OpenDocument un estándar abierto?: ¡Sí! > 13David A. WheelerTrampas ocultas en OpenDocument y efectos secundarios en el softwarelibre y de código abierto > 19Marco FiorettiISO-26300 (OpenDocument) vs. MS-Office Open XML > 22Alberto Barrionuevo GarcíaInteroperabilidad: ¿se impondrá el verdadero formato universal de ficheros? > 28Sam Hiser, Gary EdwardsODF: el Formato de Documento emergente a elección de los gobiernos > 36Marino MarcichPromoción del uso de los formatos abiertos de documentos por los ProgramasIDA e IDABC > 39Miguel A. Amutio GómezUna historia resumida de los estándares abiertos en Dinamarca > 42John GøtzeFormatos estándares abiertos y software libre en la AdministraciónPública de Extremadura > 44Luis Millán Vázquez de Miguel

secciones técnicas

Enseñanza Universitaria de la InformáticaAcciones y reacciones en el camino de la mejora docente universitaria > 46Alfonso Blesa Gascón, Pablo Bueso Franc, Carlos Catalán Cantero,Raquel Lacuesta Gilaberte, Mariano Ubé SanjuánInformática GráficaProgramación de Aplicaciones Gráficas con OpenGL y Java > 51Óscar Belmonte FernándezRedes y servicios telemáticosAlgoritmo bioinspirado para la optimización de rutas en Internet > 56José Luis Gahete Díaz, Fernando Gómez GonzálezReferencias autorizadas > 63

sociedad de la información

Futuros emprendedoresStep by Step: Mens sana in corpore sano > 70Miguel Ángel Ramos Barroso, Javier Cantón Ferrero, Javier Fernández Rodríguez,Juan María Laó RamosNovática interactivaCompetencia entre estándares, ¿va a ser posible su coexistencia? > 74Foro de DebateProgramar es crearPolígonos en malla (CUPCAM 2006, problema A, enunciado) > 75Dolores Lodares González

asuntos interioresCoordinación editorial / Fe de erratas / Programación de Novática > 76Normas para autores / Socios Institucionales > 77

sumario

NováticaNováticaNováticaNováticaNovática, revista fundada en 1975 y decana de laprensa informática española, es el órgano oficial deexpresión y formación continua de ATIATIATIATIATI (Asociación deTécnicos de Informática), organización que editatambién la revista REICISREICISREICISREICISREICIS (Revista Española deInnovación, Calidad e Ingeniería del Software).NováticaNováticaNováticaNováticaNovática edita asimismo UUUUUPPPPPGRADE, revista digital deCEPISCEPISCEPISCEPISCEPIS (Council of European Professional InformaticsSocieties), en lengua inglesa, y es miembro fundadorde UPUPUPUPUPENET (UPUPUPUPUPGRADE EEEEEuropean NETNETNETNETNETwork).

<http://www.ati.es/novatica/><http://www.ati.es/reicis/>

<http://www.upgrade-cepis.org/>

ATIATIATIATIATI es miembro fundador de CEPIS CEPIS CEPIS CEPIS CEPIS (Council of European ProfessionalInformatics Societies) y es representante de España en IFIP IFIP IFIP IFIP IFIP (InternationalFederation for Information Processing); tiene un acuerdo decolaboración con ACMACMACMACMACM (Association for Computing Machinery), asícomo acuerdos de vinculación o colaboración con AdaSpainAdaSpainAdaSpainAdaSpainAdaSpain, AI2,AI2,AI2,AI2,AI2,ASTIC, RITSI ASTIC, RITSI ASTIC, RITSI ASTIC, RITSI ASTIC, RITSI e HispalinuxHispalinuxHispalinuxHispalinuxHispalinux, junto a la que participa en ProInnovaProInnovaProInnovaProInnovaProInnova.Consejo EditorialConsejo EditorialConsejo EditorialConsejo EditorialConsejo EditorialAntoni Carbonell Nogueras, Juan ManuelCueva Lovelle, Juan Antonio EstebanIriarte,Francisco López Crespo, Celestino Martín Alonso, Josep Molas i Bertrán,Olga Pallás Codina, Fernando Piera Gómez (Presidente del Consejo), RamónPuigjaner Trepat, Miquel Sàrries Griñó, Asunción Yturbe Herranz

Coordinación EditorialCoordinación EditorialCoordinación EditorialCoordinación EditorialCoordinación EditorialLlorenç Pagés Casas<pages@ati.es>Composición y autoediciónComposición y autoediciónComposición y autoediciónComposición y autoediciónComposición y autoediciónJorge Llácer Gil de RamalesTraduccionesTraduccionesTraduccionesTraduccionesTraduccionesGrupo de Lengua e Informática de ATI <http://www.ati.es/gt/lengua-informatica/>, Dpto.de Sistemas Informáticos - Escuela Superior Politécnica - Universidad Europea de MadridAdministraciónAdministraciónAdministraciónAdministraciónAdministraciónTomás Brunete, María José Fernández, Enric Camarero, Felicidad López

Secciones Técnicas - CoordinadoresSecciones Técnicas - CoordinadoresSecciones Técnicas - CoordinadoresSecciones Técnicas - CoordinadoresSecciones Técnicas - CoordinadoresAcceso y recuperación de la InformaciónAcceso y recuperación de la InformaciónAcceso y recuperación de la InformaciónAcceso y recuperación de la InformaciónAcceso y recuperación de la InformaciónJosé María Gómez Hidalgo (Universidad Europea de Madrid), <jmgomez@uem.es>Manuel J. Maña López (Universidad de Huelva), <manuel.mana@diesia.uhu.es>Administración Pública electrónicaAdministración Pública electrónicaAdministración Pública electrónicaAdministración Pública electrónicaAdministración Pública electrónicaFrancisco López Crespo (MAE), <flc@ati.es>Gumersindo García Arribas (MAP), <gumersindo.garcia@map.es>ArquitecturasArquitecturasArquitecturasArquitecturasArquitecturasEnrique F. Torres Moreno (Universidad de Zaragoza), <enrique.torres@unizar.es>Jordi Tubella Morgadas (DAC-UPC), <jordi@ac.upc.es>Auditoría SITICAuditoría SITICAuditoría SITICAuditoría SITICAuditoría SITICMarina Touriño Troitiño, <marinatourino@marinatourino.com>Manuel Palao García-Suelto (ASIA), <manuel@palao.com>Derecho y tecnologíasDerecho y tecnologíasDerecho y tecnologíasDerecho y tecnologíasDerecho y tecnologíasIsabel Hernando Collazos (Fac. Derecho de Donostia, UPV), <ihernando@legaltek.net>Elena Davara Fernández de Marcos (Davara & Davara), <edavara@davara.com>Enseñanza Universitaría de la InformáticaEnseñanza Universitaría de la InformáticaEnseñanza Universitaría de la InformáticaEnseñanza Universitaría de la InformáticaEnseñanza Universitaría de la InformáticaJoaquín Ezpeleta Mateo (CPS-UZAR), <ezpeleta@posta.unizar.es>Cristóbal Pareja Flores (DSIP-UCM), <cpareja@sip.ucm.es>Entorno digital personalEntorno digital personalEntorno digital personalEntorno digital personalEntorno digital personalAlonso Alvarez García (TID), <aag@tid.es>Diego Gachet Páez (Universidad Europea de Madrid), <gachet@uem.es>Gestión del ConocimientoGestión del ConocimientoGestión del ConocimientoGestión del ConocimientoGestión del ConocimientoJoan Baiget Solé (Cap Gemini Ernst & Young), <joan.baiget@ati.es>Informática y FilosofíaInformática y FilosofíaInformática y FilosofíaInformática y FilosofíaInformática y FilosofíaJosé Angel Olivas Varela (Escuela Superior de Informática, UCLM)Karim Gherab Martín (Indra Sistemas)Informática GráficaInformática GráficaInformática GráficaInformática GráficaInformática GráficaMiguel Chover Sellés (Universitat Jaume I de Castellón), <chover@lsi.uji.es>Roberto Vivó Hernando (Eurographics, sección española), <rvivo@dsic.upv.es>Ingeniería del SoftwareIngeniería del SoftwareIngeniería del SoftwareIngeniería del SoftwareIngeniería del SoftwareJavier Dolado Cosín (DLSI-UPV), <dolado@si.ehu.es>Luis Fernández Sanz (PRIS-EI-UEM), <lufern@dpris.esi.uem.es>Inteligencia ArtificialInteligencia ArtificialInteligencia ArtificialInteligencia ArtificialInteligencia ArtificialVicente Botti Navarro, Vicente Julián Inglada (DSIC-UPV)<{vbotti, vinglada}@dsic.upv.es>Interacción Persona-ComputadorInteracción Persona-ComputadorInteracción Persona-ComputadorInteracción Persona-ComputadorInteracción Persona-ComputadorJulio Abascal González (FI-UPV), <julio@si.ehu.es>Lengua e InformáticaLengua e InformáticaLengua e InformáticaLengua e InformáticaLengua e InformáticaM. del Carmen Ugarte García (IBM), <cugarte@ati.es>Lenguajes informáticosLenguajes informáticosLenguajes informáticosLenguajes informáticosLenguajes informáticosAndrés Marín López (Univ. Carlos III), <amarin@it.uc3m.es>J. Ángel Velázquez Itúrbide (ESCET-URJC), <a.velazquez@escet.urjc.es>Lingüística computacionalLingüística computacionalLingüística computacionalLingüística computacionalLingüística computacionalXavier Gómez Guinovart (Univ. de Vigo), <xgg@uvigo.es>Manuel Palomar (Univ. de Alicante), <mpalomar@dlsi.ua.es>Mundo estudiantilMundo estudiantilMundo estudiantilMundo estudiantilMundo estudiantilAdolfo Vázquez Rodríguez (Rama de Estudiantes del IEEE-UCM), <a.vazquez@ieee.org>Federico G. Mon Trotti (RITSI) <gnu.fede@gmail.com>Profesión informáticaProfesión informáticaProfesión informáticaProfesión informáticaProfesión informáticaRafael Fernández Calvo (ATI), <rfcalvo@ati.es>Miquel Sàrries Griñó (Ayto. de Barcelona), <msarries@ati.es>Redes y servicios telemáticosRedes y servicios telemáticosRedes y servicios telemáticosRedes y servicios telemáticosRedes y servicios telemáticosJosé Luis Marzo Lázaro (Univ. de Girona), <joseluis.marzo@udg.es>Josep Solé Pareta (DAC-UPC), <pareta@ac.upc.es>SeguridadSeguridadSeguridadSeguridadSeguridadJavier Areitio Bertolín (Univ. de Deusto), <jareitio@eside.deusto.es>Javier López Muñoz (ETSI Informática-UMA), <jlm@lcc.uma.es>Sistemas de Tiempo RealSistemas de Tiempo RealSistemas de Tiempo RealSistemas de Tiempo RealSistemas de Tiempo RealAlejandro Alonso Muñoz, Juan Antonio de la Puente Alfaro (DIT-UPM),<{aalonso,jpuente}@dit.upm.es>Software LibreSoftware LibreSoftware LibreSoftware LibreSoftware LibreJesús M. González Barahona, Pedro de las Heras Quirós (GSYC-URJC),<{jgb,pheras}@gsyc.escet.urjc.es>Tecnología de ObjetosTecnología de ObjetosTecnología de ObjetosTecnología de ObjetosTecnología de ObjetosJesus García Molina (DIS-UM), <jmolina@um.es>Gustavo Rossi (LIFIA-UNLP, Argentina), <gustavo@sol.info.unlp.edu.ar>Tecnologías para la EducaciónTecnologías para la EducaciónTecnologías para la EducaciónTecnologías para la EducaciónTecnologías para la EducaciónJuan Manuel Dodero Beardo (UC3M), <dodero@inf.uc3m.es>Julià Minguillón i Alfonso (UOC), <jminguillona@uoc.edu>.Tecnologías y EmpresaTecnologías y EmpresaTecnologías y EmpresaTecnologías y EmpresaTecnologías y EmpresaDidac López Butifull (Universitat de Girona), <didac.lopez@ati.es>Francisco Javier Cantais Sánchez (Indra Sistemas), <fjcantais@gmail.com>TIC y TurismoTIC y TurismoTIC y TurismoTIC y TurismoTIC y TurismoAndrés Aguayo Maldonado, Antonio Guevara Plaza (Univ. de Málaga)<{aguayo, guevara}@lcc.uma.es>

Las opiniones expresadas por los autores son responsabilidad exclusiva delosmismos. NováticaNováticaNováticaNováticaNovática permite la reproducción, sin ánimo de lucro, de todos losartículos, a menos que lo impida la modalidad de © o copyright elegida por elautor, debiéndose en todo caso citar su procedencia y enviar a NováticaNováticaNováticaNováticaNovática unejemplar de la publicación.

Coordinación Editorial, Redacción Central y Redacción ATI MadridCoordinación Editorial, Redacción Central y Redacción ATI MadridCoordinación Editorial, Redacción Central y Redacción ATI MadridCoordinación Editorial, Redacción Central y Redacción ATI MadridCoordinación Editorial, Redacción Central y Redacción ATI MadridPadilla 66, 3º, dcha., 28006 MadridTlfn.914029391; fax.913093685 <novatica@ati.es>Composición, Edición y Redacción ATI ValenciaComposición, Edición y Redacción ATI ValenciaComposición, Edición y Redacción ATI ValenciaComposición, Edición y Redacción ATI ValenciaComposición, Edición y Redacción ATI ValenciaAv. del Reino de Valencia 23, 46005 ValenciaTlfn./fax 963330392 <secreval@ati.es>Administración y Redacción ATI CataluñaAdministración y Redacción ATI CataluñaAdministración y Redacción ATI CataluñaAdministración y Redacción ATI CataluñaAdministración y Redacción ATI CataluñaVia Laietana 46, ppal. 1ª, 08018 BarcelonaTlfn.934125235; fax 934127713 <secregen@ati.es>Redacción ATI AndalucíaRedacción ATI AndalucíaRedacción ATI AndalucíaRedacción ATI AndalucíaRedacción ATI AndalucíaIsaac Newton, s/n, Ed. Sadiel,Isla Cartuja 41092 Sevilla, Tlfn./fax 954460779 <secreand@ati.es>Redacción ATI AragónRedacción ATI AragónRedacción ATI AragónRedacción ATI AragónRedacción ATI AragónLagasca 9, 3-B, 50006 Zaragoza.Tlfn./fax 976235181 <secreara@ati.es>Redacción ATI Asturias-CantabriaRedacción ATI Asturias-CantabriaRedacción ATI Asturias-CantabriaRedacción ATI Asturias-CantabriaRedacción ATI Asturias-Cantabria <gp-astucant@ati.es>Redacción ATI Castilla-La ManchaRedacción ATI Castilla-La ManchaRedacción ATI Castilla-La ManchaRedacción ATI Castilla-La ManchaRedacción ATI Castilla-La Mancha <gp-clmancha@ati.es>Suscripción y VentasSuscripción y VentasSuscripción y VentasSuscripción y VentasSuscripción y Ventas<http://www.ati.es/novatica/interes.html>, o en ATI Cataluña o ATI MadridPublicidadPublicidadPublicidadPublicidadPublicidadPadilla 66, 3º, dcha., 28006 MadridTlnf.914029391; fax.913093685 <novatica@ati.es>ImprentaImprentaImprentaImprentaImprentaDerra S.A., Juan de Austria 66, 08005 Barcelona.Depósito legal:Depósito legal:Depósito legal:Depósito legal:Depósito legal: B 15.154-1975 -- ISSN: 0211-2124; CODEN NOVAECPortada:Portada:Portada:Portada:Portada: "Alan Turing & friends" (variaciones sobre una foto tomada de www.tuning.org).RFCalvo / © Rafael Fernández Calvo 2007Diseño:Diseño:Diseño:Diseño:Diseño: Fernando Agresta / © ATI 2006

novática nº 184 noviembre-diciembre 20062

editorial

La enseñanza de la Informática en EspañaLa enseñanza de la Informática en EspañaLa enseñanza de la Informática en EspañaLa enseñanza de la Informática en EspañaLa enseñanza de la Informática en España

Desde su fundación, ATI se ha preocupado porel desarrollo de la educación en Informática, entodos sus aspectos y en todos sus niveles, tantopor el interés del desarrollo de sus propios so-cios, como por el papel que desempeña en nues-tra sociedad como primera asociación dedicadaa la promoción y al desarrollo de la Informáticaen España.

Por ello, ATI está siguiendo muy de cerca lostrabajos que el Ministerio de Educación estállevando a cabo en la determinación de los con-tenidos de las enseñanzas de informática en lanueva estructura educativa establecida por lareciente LOE.

ATI ha participado en alguna de las reunionesque los profesores de Informática de la ESO yBachillerato, encabezados por la PNAPI (Plata-forma Nacional de Asociaciones de Profesoresde Informática), han mantenido con las autori-dades del Ministerio de Educación para tratarprecisamente de este tema.

A ATI le sorprende enormemente que a princi-pios del siglo XXI y en plena reforma de lasenseñanzas medias de nuestro país, el Ministe-rio de Educación español prescinda de la ense-ñanza de la informática en la ESO salvo en elultimo curso, pretendiendo que se impartan bos-quejos de la misma dentro de una asignaturadenominada "Tecnología" impartida por profe-sores totalmente ajenos a la Informática. Con elagravante de que la citada asignatura tiene uncontenido mucho más parecido a unas enseñan-zas de bricolaje que a uno realmente serio.

Paradójicamente, el documento Una Educaciónde Calidad para Todos y entre Todos elaboradopor el propio Ministerio de Educación habla de"una fractura social, que aumenta en progresióngeométrica, entre quienes están alfabetizados ennuevas tecnologías y quienes no lo están", que"muchas familias buscan fuera del marco escolar,y de un modo individual, el logro para sus hijos deestos objetivos en academias" y que "todo elloestá acrecentando esa fractura social".

Precisamente, la exclusión de una asignatura deInformática obligatoria a lo largo de toda la ESOy el Bachillerato es uno de los detonantes clave deesa brecha digital denunciada por el Ministerio deEducación. Habrá grupos de jóvenes a los que noles guste la informática o no tengan esa predispo-sición y medios particulares, que no elegirán laoptativa establecida en cuarto de ESO, y sufriránpor ello esa fractura social que tanto parecepreocupar al Gobierno.

Se precisa por tanto animar a las CCAA, sininterferir en sus competencias, al cumplimientodel artículo 1 de la LOE que habla de calidad dela enseñanza y de una educación integral.

Por otra parte, la definición de la informáticadada por el Ministerio de Educación ha sesgadode su significado el componente científico-técni-co que sustenta el desarrollo de esta materiacientífica, dejando el vocablo totalmente reduci-do al nivel de usuario. Es una definición incom-pleta, y por tanto incorrecta, cuya redaccióntextual es: "La informática es el conjunto deconocimientos científicos y técnicos que hacen

posible el tratamiento automático de la informa-ción por medio de ordenadores. Abarca portanto los conceptos, procedimientos y actitudesque permiten tanto el diseño como el uso yaprovechamiento de las tecnologías de la infor-mación y la comunicación en cualquiera de lasformas en que éstas se nos presentan".

Por lo tanto, el Ministerio de Educación noparece haber tenido en cuenta el informe de laUNESCO de 2002 "Information andCommunication Technology in Education: ACurriculum for Schools and Programme ofTeacher Development" sobre las enseñanzas dela Informática y en cuya redacción tuvo un papelrelevante la IFIP, en la que ATI representa aEspaña.

La conclusión a la que se puede llegar después deestas consideraciones es que la actitud del Mi-nisterio de Educación en este nivel de la ense-ñanza secundaria solo conduce a aumentar ladenominada brecha digital y a perjudicar direc-tamente a los informáticos españoles, por lo queATI eleva su protesta a las autoridades compe-tentes y llama la atención del Ministerio deIndustria, pues su política para el desarrollo dela Sociedad de la Información queda evidente-mente en cuestión.

Otra cosa distinta ocurre a nivel de la enseñanzaprofesional de la Informática, donde el INCUAL(Instituto Nacional de las Cualificaciones), tam-bién del Ministerio de Educación, con el quedesde ATI colaboramos dentro de nuestras po-sibilidades, sí sigue las pautas europeas.

Llorenç PLlorenç PLlorenç PLlorenç PLlorenç Pagés Casasagés Casasagés Casasagés Casasagés CasasCoordinación Editorial de NováticaNováticaNováticaNováticaNovática

en resumen Un estándar, dos estándares

Queridos lectores/as:

Quizás resulte sorprendente que de entradaos diga que la monografía que encontrareisen este número no es lo que en su día preten-dió ser. Tiene fácil explicación: cuando pro-gramamos este número, ODF acababa deconvertirse en estándar ISO y eso augurabauna unanimidad en su uso como formatoestándar de documentos similar, por ejem-plo, al que ha obtenido XML como formatode intercambio de datos.

Pero llegado el momento de editar la mono-grafía nos encontramos que a ODF le hasalido una alternativa muy relevante(EOOXML) promovida principalmente porMicrocoft, la empresa dominante en el mer-cado del software ofimático. Con el consi-guiente malestar de quienes trabajaron du-rante más de 6 años en la idea de lograr unformato estándar de documentos consen-suado que asegurase una interoperabilidadplena, ahora en entredicho por razones téc-nicas consecuentes a la existencia de más deun estándar.

Así pues nos encontramos con que si elrasgo distintivo de los contenidos deNovática Novática Novática Novática Novática suele ser su carácter científico ytécnico-divulgativo, esta monografía seconvierte sobre todo en un documento pe-riodístico de vivísima actualidad. Hasta elpunto de que el dia 5 de febrero vence elplazo de alegaciones a la propuesta de apro-bación de EOOXML como estándar ISO ylas voces proclamando la inconveniencia deque se produzca dicha aprobación se estánhaciendo notar en los medios.

Sin duda, el tema va a deparar muchostitulares de prensa en un próximo futuro. Yen este número de NováticaNováticaNováticaNováticaNovática encontrareisalgunas de sus claves más relevantes anali-zadas en profundidad. Aderezadas en algu-nos momentos con afirmaciones duras ydescalificadoras propias de una situación deconflicto de intereses.

Ante ello solamente nos queda reafirmar nues-tra vocación de pluralidad y de objetividad a lahora de escoger nuestros contenidos. Y paramuestra un botón: si en el número anteriorpresentábamos en nuestra sección "FuturosEmprendedores" el proyecto de los ganado-res de un concurso universitario promovidopor Sun, en esta ocasión nos ha tocado

casualmente presentar el proyecto ganadorde la Imagine Cup 2006 de Microsoft.

De todas formas, y hablando ya a títuloparticular, es obvio que en la vida nunca hayque permanecer indiferentes ante los temascontrovertidos sino analizar, formarse unaopinión y ser capaces de expresarla. Es estolo que os proponemos que hagamos en eldebate que lanzamos desde "NováticaInteractiva" y que, apuntad esa fecha, empe-zará el próximo dia 5 de marzo en los forosde Internet de ATI, seguramente aún con eldebate mediático sobre los dos estándaresofimáticos en su punto más álgido.

Un agradecimiento muy sincero a todos quie-nes han contribuido a este número deNováticaNováticaNováticaNováticaNovática y en especial a los editores invita-dos a la monografía Jesús Tramullas, Pie-Jesús Tramullas, Pie-Jesús Tramullas, Pie-Jesús Tramullas, Pie-Jesús Tramullas, Pie-dad Garridodad Garridodad Garridodad Garridodad Garrido y Marco FiorettiMarco FiorettiMarco FiorettiMarco FiorettiMarco Fioretti sin cuyosdesvelos no hubiera sido posible este docu-mento, tanto técnico como "periodístico",que ahora está en vuestras manos.

novática nº 184 noviembre-diciembre 2006 3

Noticias de IFIPNoticias de IFIPNoticias de IFIPNoticias de IFIPNoticias de IFIP

En la reunión de este comité técnico, celebradaen París (Francia) el pasado 29 y 30 de septiem-bre, entre otros se tomaron los siguientes acuer-dos:1. Nombrar Chairman del WG6.2 Network and

Internetwork Architectures al Prof. Georg Carledel Wilhelm-Schickard-Institut für Informatikde Tübingen (Alemania) al haber pasado elanterior chairman, Prof. Guy Pujolle, a ser elrepresentante de Francia en el TC6.

2. Nombrar Chairman del WG6.8 Mobile andWireless Communications al Prof. Pedro Cuen-ca de la Universidad de Castilla-La Mancha(Albacete) al haber alcanzado el anterior chair-man, Dr. Guy Omydiar el término de su man-dato. En este grupo de trabajo se instó al nuevochairman a que ampliara las actividades delmismo para incorporar, entre otras, las redessensoriales y las redes ad-hoc.

3. Nombrar Chairman del WG6.10 PhotonicNetworking, al Prof. Ioannis Tomkos de laAthens Information Technology (Grecia) yVice-Chairman al Prof. Josep Solé Pareta dela Universitat Politècnica de Catalunya. Aambos se les encomendó la misión de reavi-var las tareas de este grupo de trabajo que,recientemente, ha pasado por una crisis ensus actividades.

4. Poner en marcha el procedimiento de elec-ción del chairman del TC6 al haberse cum-plido los tres años desde la elección del Prof.Otto Spaniol de la Rheinisch-WestfälischeTechnische Hochschule Aachen (Alemania),

aunque éste podía ser reelegido. En octubretendría lugar la presentación de candidatos yen noviembre se efectuaría la votación elec-trónica a traves del correo electrónico (verlos resultados más abajo).

5. Confirmar el plan de trabajo estudiado en lareunión extraordinaria sobre actividades enpaíses en desarrollo, celebrada a finales deagosto en Santiago de Chile. En ella se acordó:

a) Continuar con las actividades lanzadas desdehace unos años en América Latina, con la LatinAmerican Networking Conference LANC (la proximase celebrá en octubre del 2007 en San José de CostaRica) como actividad fundamental.b) Iniciar la colaboración con la Universidad delas Naciones Unidas (UNU) y la realización decursos en diversos países africanos (Mozambique,Etiopía, República Sudafricana) coincidiendo conotras actividades que IFIP desarrollará en esecontinente en los próximos años (WITFOR 2007en Adis Abeba, conferencia en la RSA en 2008),contando con la colaboración de entidades loca-les (Universidad de Mozambique).6. Además se trataron los asuntos corrientes

concernientes a las actividades regulares(conferencias, workshops, etc.) de todos losgrupos de trabajo.

Elección de ChairmanA la elección para chairman del TC6 para elperíodo 2007-2009 podían presentarse los repre-sentantes de países en el TC6 que hubieran asis-tido a, por lo menos, una de las tres últimas

reuniones. Se presentaron dos candidatos:El Prof. Otto Spaniol de la Rheinisch-

Westfälische Technische Hochschule Aachen(Alemania), representante de Alemania en elTC6.

El Prof. Guy Leduc de la Université de Liège(Bélgica), representante de Bélgica en el TC6.

Tenían derecho de voto todos los representan-tes que hubieran asistido a, por lo menos, unade las tres últimas reuniones y todos loschairpersons de los distintos grupos de trabajo(WG). En total tenían derecho de voto 35personas. La votación se realizó en el mes denoviembre vía e-mail siendo los receptores elsecretario del TC6 y el secretariado de IFIP(para cubrir la posibilidad de pérdida de men-sajes, como a veces sucede), y el resultado fue:

Prof. Otto Spaniol, 12 votos.Prof. Guy Leduc, 20 votos.Abstenciones, 3.

Así pues ha quedado proclamado nuevo chair-man del TC6, el Prof. Guy Leduc cuyo manda-to empezará el próximo 1 de enero de 2007.

A remarcar la participación de todas las perso-nas que tenían derecho de voto, lo que pone demanifiesto el interés de esta elección por elcambio no sólo de persona sino generacionalque significa y que ha de permitir llevar adelan-te los cambios que necesita la IFIP, en general,y, en particular el TC6.

Actividades del IFIP TC6Technical Committee on Communication Networks

Ramón Puigjaner TrepatDelegado Permanente de ATI en IFIP y en el TC6, Vocal de la Junta Directiva General de ATI

<putxi@uib.es><putxi@uib.es><putxi@uib.es><putxi@uib.es><putxi@uib.es>

En la reunión anual del TC12, el presidentedel comité técnico Profesor Max Bramerinformó a los miembros de dicho comité delas siguientes actividades llevadas a cabodurante el último año.

Nuevos miembros en el TC12:Gintautas Dzemyda (Institute of

Mathematics and Informatics), NikolaBogunovic (University of Zagreb) y HelderCoelho (University of Lisbon) son los nue-vos representanes de Lituania, Croacia yPortugal,respectivamente.

Rose Dieng (INRIA, Francia), es la nuevapresidenta del grupo de trabajo WG12.6, ysustituye Eric Tsui en el TC12.

Enrique Gonzalez es el nuevo represen-tante de CLEI en el TC12.

Actividades de los grupos de trabajo:El WG12.2 ("Machine Learning & Data

Mining"), en colaboración con el WG12.5,participó en la organización y realización delcongreso "Artif icial Intel l igence and

Innovations" (AIAI-2005 ) que se celebró enBeijing del 7 al 9 de septiembre de 2005. ElWG12.2 organizó tambien otros congresosen Adelaida (International Conference onIntelligent Information Processings, ICIIP2006) y el workshop sobre agentes autóno-mos PRIMA 2006 en Guilin (China).

El WG12.4 ("Semantic Web") organizó,conjuntamente con el WG2.12 (del TC2), elworkshop sobre "Semantic web & WebSemantics" (SWWS’05) en Agai Napa (Chi-pre) lo dias 1 y 2 de noviembre de 2005.

El WG12.5 ("Artif icial Intel l igenceApplications") organizó el tercer congresoIFIP AI 2006 del 20 al 25 de Agosto enSantiago de Chile dentro del marco del Con-greso Mundial de IFIP.

El WG12,6 ("Knowledge Management")organizó, los dias 28 y 29 de Agosto, elECAI-2006 workshop sobre "KnowledgeManagement and Organizational Memories"en Riva del Garda (Italia) dentro del marcodel Congreso Europeo de Inteligencia Artifi-cial (ECAI’2006).

Una de las decisiones mas importantes, to-madas durante el último año, ha sido lacreación de una "Task Force" para estudiarposibles actividades de ayuda al desarrollode la Inteligencia Artificial en paises en viasde desarrollo. Esta "Task Force" está com-puesta por miembros representantes de Ita-lia, Eslovenia, República Checa, Eslovaquia,Francia, Alemania, EEUU, India y Dina-marca. La primera decisión de este grupo derepresentantes ha sido lanzar una iniciativapara otorgar un premio a la mejor tesisdoctoral sobre Inteligencia Artificial desa-rrollada preferentemente en algunos de lospaises considerados "menores" en cuanto aactividades en dicha materia. Inicialmenteesta competición por el citado premio inclu-ye tesis doctorales de los siguientes paises:India, Serbia y Eslovenia.

Ramón López de Mántaras, Ramón López de Mántaras, Ramón López de Mántaras, Ramón López de Mántaras, Ramón López de Mántaras, representanteespañol en el TC12 y socio de ATI.

Actividades del IFIP TC12 (Artificial Intelligence) durante el período agosto 2005-agosto 2006

novática nº 184 noviembre-diciembre 20064

monografía Formato de Documento Abierto (ODF)

monografía

Presentación:OpenDocument, estándar para

documentos digitales

Editores invitadosEl auge y expansión del movimiento de soft-ware libre, las ilimitadas posibilidades delmismo, y el creciente éxito que están tenien-do las herramientas de software libre en elcontexto comercial y de negocios han dejadoen un segundo plano varias cuestiones claveque, a su vez, son inherentes al mismo movi-miento. Nos estamos refiriendo, como esobvio, a los estándares abiertos, elementosnucleares para la interoperabilidad de lasaplicaciones de software. Son los estándareslos que establecen las reglas del juego enmuchos aspectos y funcionalidades de lasherramientas software. Es el cumplimientode estándares, sean de facto o de iure, lo quepuede determinar el éxito o fracaso de unaaplicación. Gran parte de la actividad dedesarrollo de software está guiada porestándares, al igual que la tan traída y lleva-da "calidad".

Por ello, aún llama más la atención el pocointerés que habían despertado los estándaresen los últimos años. Evidentemente, unaaplicación es más vistosa (y provechosa) queun estándar técnico, máxime si además setrata de un estándar abierto. Sin embargo,las primeras son imposibles sin los segun-dos. La mayoría de los protocolos sobre losque se fundamenta la comunicación y trans-ferencia de información en Internet sonestándares abiertos (o casi). El World WideWeb Consortium dedica sus esfuerzos a laformulación y aceptación de estándares,conocedores que de sin ellos sería imposiblecontinuar el desarrollo de la red y de losservicios avanzados de información. Con-trasta este hecho con la carencia de estándarespara la información más ampliamente crea-da y difundida a nivel mundial: la que sealmacena en documentos ofimáticos.

El que controla el escritorio de los usuarios,controla sus aplicaciones. Y el 80% de losusuarios de ordenadores trabaja con aplica-ciones clásicas de escritorio, con el procesadorde texto o la hoja de cálculo. El trabajo deoficina en las empresas, la actividad de lasadministraciones públicas, o el entorno educa-tivo, son ejemplos de un uso intensivo de laofimática. La información que usan, generan ytransforman se almacena en documentosofimáticos. Los formatos de estos documentoshan establecido unos estándares de facto que,ladinamente, han servido para fijar unas nor-mas a todos los usuarios, en numerosas oca-siones abusivas, que limitan la libertad de

Jesús Tramullas Saz1, PiedadGarrido Picazo2

1Depto. Ciencias de la Documentación, Uni-versidad de Zaragoza; 2Depto. Informáticae Ingeniería de Sistemas, Universidad. deZaragoza

<jesus@tramullas.com>, <piedad@unizar.es><jesus@tramullas.com>, <piedad@unizar.es><jesus@tramullas.com>, <piedad@unizar.es><jesus@tramullas.com>, <piedad@unizar.es><jesus@tramullas.com>, <piedad@unizar.es>

Jesús Tramullas Saz es profesor titular en el Depto. de Ciencias de la Documentación de la Univer-sidad de Zaragoza. Miembro del grupo de investigación sobre Gestión de Recursos de Informa-ción en las Organizaciones (GRIO). Coordinador de la Red temática sobre Documentación Digital(Plan Nacional de I+D+I, 2004–2005 y 2006-2007). Investigador principal del proyecto "Websemántico y bibliotecas digitales: desarrollo de servicios de información basados en RDF y TopicMaps" (2006–2007). Sus líneas de investigación se centran en bibliotecas digitales y servicios deinformación digital, gestión de contenidos y herramientas de software libre para la gestión deinformación. Mantiene la traducción al español del software libre Greenstone Digital Library Soft-ware.

Piedad Garrido Picazo es profesora asociada en el Depto. de Informática e Ingeniería de Sistemasde la Universidad de Zaragoza. Miembro del grupo de investigación sobre Gestión de Recursos deInformación en las Organizaciones (GRIO). Pertenece a las redes temáticas sobre Recuperaciónde Información en Textos y Bibliotecas Digitales, Documentación Digital, y Sistemas de Acceso a laInformación en la Web basados en Soft–Computing. Sus líneas de investigación son bases dedatos xml, software libre para gestión de información, bibliotecas digitales, RDF y Topic Maps(XTM) en el contexto del web semántico.

Ambos han coordinado el libro Software libre para servicios de información digital, Madrid: PrenticeHall, 2006.

decisión, la compatibilidad y la interopera-bilidad, y obligan a asumir como normalesunos costes que, en cualquier otro contexto,serían inmediatamente calificados como abu-so de posición dominante y contrarios a la librecompetencia.

La existencia de un estándar es aconsejablepor definición. Establece requerimientos yreglas de juego. El uso que se haga delmismo puede, en cambio, ofrecer resultadosno deseados, cuando entran en juego paten-tes y limitaciones legales que favoren a unaparte frente al resto. Por ello resulta estraté-gico que los estándares sean abiertos, desa-rrollados en un entorno de colaboraciónentre iguales, y que su especificación nocontenga limitaciones encubiertas que difi-culten su utilización. Si además estosestándares aseguran a todos los ciudadanosel derecho a acceder, almacenar y transfor-mar la información digital, independiente-mente de la plataforma informática que uti-licen para ello, adquieren inmediatamenteun valor económico, social y político incal-culable.

OpenDocument es un estándar (el únicoestándar) para documentos ofimáticos quereúne en sí mismo todas las característicasdeseables. Ha sido refrendado por laInternational Organization for Standardization

(ISO), como estándar ISO/IEC 26300:2006,en su versión 1.0. Es resultado del trabajoabierto y en colaboración de los principalesactores, tanto desarrolladores de software,como implementadores de soluciones, comousuarios finales. Es público y gratuito, y losrequerimientos legales que incluye evitan posi-bles usos parciales o abusivos del mismo. Ade-más, hace uso de otros estándares abiertos ensu propia especificación, como XML(eXtensible Markup Language), SVG (ScalableVector Graphics) o Dublin Core.OpenDocument ya había sido desarrollado yaprobado como estándar por la Organizationfor the Advancement of Structured InformationStandards, OASIS, en 2005, lo que asegura elapoyo y la evolución del mismo por parte de laprincipales actores de la industria.

Sin embargo, OpenDocument no es un meroestándar para formato de documentosofimáticos. La filosofía que subyace al mis-mo es diferente. Algunos pueden argüir queun estándar es un aspecto técnico, y nadamás, y formalmente pueden tener razón.Pero precisamente la excelencia técnica deOpenDocument, indudable y superior a lade cualquier otro formato existente paradocumentos ofimáticos, viene del enfoquefilosófico de partida, y en la forma en queéste se ha plasmado en métodos y técnicas detrabajo, y en el producto final resultante. El

novática nº 184 noviembre-diciembre 2006 5

Formato de Documento Abierto (ODF) monografía

monografía

trabajo en colaboración, abierto y democrá-tico ha permitido la intervención de todos losimplicados, lo que asegura la respuesta amúltiples y variadas demandas. La implica-ción de la industria asegura la presencia en elmercado de productos que cumplen elestándar, asegurando la portabiilidad y lainteroperabildiad entre plataformas. Cual-quier ciudadano puede acceder al documen-to que contiene la especificación técnica, porlo que la información contenida en los docu-mentos en formato OpenDocument no que-da sujeta a decisiones arbitrarias de terceros.Además, este enfoque abierto promueve lacompetencia entre productos, y ante lasmúltiples opciones, los usuarios pueden optarlibremente por la que consideren más ade-cuada a sus necesidades o más avanzadatécnicamente. Esta independencia no sólo esdeseable, sino necesaria e ineludible.

OpenDocument es un formato preparadopara la web semántica. Todo el etiquetadosigue el estándar XML. Los documentos

pueden incluir el estándar de metadatosDublin Core (norma ISO 15:836:2003). Sepueden obtener diferentes resultados de sa-lida utilizando XSLT. Al tratarse de docu-mentos de texto etiquetados en XML, lasherramientas y librerías para motores debúsqueda, como Lucene o Xapian, puedenprocesarlos con un mínimo de carga. Porejemplo, la combinación con otros estándarespuede permitir generar Topic Maps (normaISO/IEC 13250:2003) partiendo del conte-nido de un documento, con lo que ello puedesignificar para el desarrollo de sistemas deextracción y representación de la informa-ción.

Una cuestión de suma importancia, que amenudo queda completamente oculto, es lapreservación de la información digital. Aun-que muchas organizaciones aún no son cons-cientes de ello, la preservación a medio ylargo plazo de los activos digitales, granparte de los cuales se encuentra en docu-mentos ofimáticos, supone una preocupa-

Referencias útiles sobre el "Formato de Documento Abierto (ODF)"

Especificación OpenDocument versión 1.0,<http://www.oasis-open.org/committees/download.php/12572/OpenDocument-v1.0-os.pdf>.OASIS OpenDocument Essentials, <http://books.evc-cit.info/>.Opportunities for Innovation with OpenDocument Format XML, <http://opendocument.xml.org/files/LOW10771-USEN-00.pdf>.OpenDocument -Formula TC, <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office-formula>.OASIS OpenDocument Format for OfficeApplications, <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office>.

The OpenDocument Foundation, <http://opendocumentfoundation.us/>.OpenDocument Format Alliance, <http://www.odfalliance.org/>.OpenDocument Fellowship, <http://opendocumentfellowship.org/>.Technorati: OpenDocument, <http://technorati.com/posts/tag/OpenDocument>.OpenDocument xml.com, <http://opendocument.xml.org/>.Open Interoperative Document Initiative,<http://www.oidi.org/tiki-index.php>.OpenDocument Format Viewer, <http://opendocumentfellowship.org/odfviewer>.OpenOffice, <http://www.openoffice.org/>.Koffice, <http://www.koffice.org/>.O Reilly ONLamp: What Is OpenDocument,

<http://www.onlamp.com/pub/a/onlamp/2006/07/27/what-is-opendocument.html>.Blog de Sam Hiser, <http://fussnotes.typepad.com/plexnex/>.Blog de Andy Updegrove, <http://www.consortiuminfo.org/standardsblog/>.Blog de Bob Sutor, <http://www.sutor.com/newsite/blog-open/>.Blog de Charles H. Schulz, <http://www.libervis.com/blogs/5/charles>.Blog de David A. Wheeler, <http://www.dwheeler.com/>.Blog de Erwin Tenhunberg, <http://blogs.sun.com/dancer/>.Blog de Ron Weir, <http://www.robweir.com/blog/index.html>.

ción creciente, tanto por cuestiones de ges-tión del conocimiento de la propia organiza-ción, como por cuestiones legales relaciona-das con las actividades que desarrollan. Sibien hay un estándar para preservación dedocumentos digitales a largo plazo (ISO19005-1:2005), mediante PDF, lo cierto esque éste sólo sirve para versiones finales deun documento. OpenDocument está prepa-rado para mantener un registro de actividadsobre el contenido del documento, así comopara "recordar", por ejemplo, las fórmulasque han generado un resultado matemático.

Si a ello unimos la creciente demanda degestión de registros y documentos en el con-texto de administraciones públicas, de em-presas, etc., que además tiene un conjunto denormas propio (ISO 15489-1/2:2001 RecordsManagement; UNE/ISO 15489-1/2:2006Gestión de Documentos), se puede afirmarque OpenDocument tiene un largo recorridoy un extenso campo que cubrir.

¿Estudiante de Ingeniería Técnica oIngeniería Superior de Informática?Puedes aprovecharte de las condiciones especialespara hacerte socio estudiante de ATIy gozar de los servicios que te ofrece nuestra aso-

ciación, según el acuerdo firmado con la

Asociación RITSIInfórmate en www.ati.es

o ponte en contacto con la Secretaría de ATI Madridsecremdr@ati.es, teléfono 91 4029391

www.ati.es www.ritsi.org

novática nº 184 noviembre-diciembre 20066

monografía Formato de Documento Abierto (ODF)

monografía

1. Por qué es importante un for-mato abiertoEn un mundo en el que los archivos electró-nicos reemplazan cada vez en mayor medidaa los documentos en papel, es fundamentalasegurar el acceso y funcionalidad de estadocumentación a largo plazo. Especialmen-te afectados se ven los contratos legales ydocumentos gubernamentales, que son váli-dos y relevantes durante décadas o inclusosiglos. Sin embargo, los documentos perso-nales tampoco son menos importantes.

Del mismo modo que hay múltiples fabri-cantes de papel y bolígrafos, y no uno sólo,es necesario que varios fabricantes soporteny proporcionen estos formatos de archivos ylas aplicaciones que crean estos formatos.Esto garantizará el acceso a largo plazo a losdatos, aunque las empresas dejen de seroperativas, cambien su estrategia o aumen-ten sus precios de forma exorbitante. Enefecto, al poder elegir, el usuario mantiene elcontrol y la propiedad de los documentosque crea. Ya no depende de un solo fabrican-te para leer o modificar su trabajo.

Los estándares abiertos que son igualmenteaccesibles y no favorecen a ningún fabrican-te en particular pueden contribuir a mante-ner un ecosistema diverso de fabricantes.Esto también fomenta los precios competiti-vos, creando así las condiciones para el me-jor uso del dinero tanto de los inversorescomo de los contribuyentes.

En el caso de los documentos públicos quelas administraciones facilitan a los ciudada-nos, también es importante no excluir a nin-gún ciudadano del acceso a los datos. Lainformación pública ha de ser accesible paratodos los ciudadanos independientementede sus ingresos y capacidad física. En estesentido, la accesibilidad tiene un significadocompletamente diferente para las personascon discapacidad. Un estándar abierto quetrate con datos de documentos debe diseñar-se también para permitir la adición de unaserie de tecnologías de ayuda, de forma queuna persona invidente o con un bajo gradode visión, parálisis o incluso graves limita-ciones motoras, pueda tener acceso suficien-te al software y a los datos como para podercrear y leer documentos de forma efectiva.La reciente especificación ODF v.1.1Committee Specification 1 aborda estas ne-cesidades. Siguiendo la tradición del desa-

rrollo de estándares abiertos, el Comité Téc-nico de ODF de OASIS estableció un subco-mité de expertos técnicos en el campo detecnología accesible. Este subcomité(Accessibility SC) estableció el ambiciosoobjetivo de satisfacer y superar el soporte a laaccesibilidad disponible en la actualidad enel formato de archivo predominante en laindustria, así como lo que está especificadoen las Pautas de Accesibilidad al Contenidoen la Web 1.0 del W3C.

Dicho subcomité también reconoció la nece-sidad de proporcionar directrices de

implementación a los desarrolladores de apli-caciones para garantizar que las solucionespropuestas que soporten ODF satisfagan lasnecesidades de las personas condiscapacidad, para lo que se han incluidotoda una serie de requisitos. El resultado sonlas "Pautas de accesibilidad para implemen-taciones del formato OpenDocument v.1.1."(Accessibility Guidelines forImplementations of OpenDocument Formatv1.1) [1].

Los estándares abiertos reducen las barrerasde entrada, permitiendo a otras empresas

Abierto desde el diseño: elFormato de Documento Abierto

para aplicaciones ofimáticas

Erwin Tenhumberg, DonaldHarbison, Rob WeirComité Técnico de Adopción de ODF, OASIS

<erwin.tenhumberg@sun.com>,<erwin.tenhumberg@sun.com>,<erwin.tenhumberg@sun.com>,<erwin.tenhumberg@sun.com>,<erwin.tenhumberg@sun.com>,<donald_harbison@us.ibm.com>,<donald_harbison@us.ibm.com>,<donald_harbison@us.ibm.com>,<donald_harbison@us.ibm.com>,<donald_harbison@us.ibm.com>,<robert_weir@us.ibm.com><robert_weir@us.ibm.com><robert_weir@us.ibm.com><robert_weir@us.ibm.com><robert_weir@us.ibm.com>

Traducción:Traducción:Traducción:Traducción:Traducción: Laura Ramírez Polo (Grupo de Trabajo de Lengua e Informática de ATI)

Resumen: este artículo describe los antecedentes y la historia que dio lugar al Formato de DocumentoAbierto, ahora disponible como norma ISO/IEC 26300:2006. Cubre aspectos tales como el valor de unformato abierto de ficheros, sus beneficios a corto y a largo plazo, interoperabilidad, soberanía einnovación. Se trata de un ensayo colaborativo escrito por destacados miembros del OpenDocumentFormat Adoption TC un comité técnico de OASIS cuyo objetivo es difundir e impulsar la demanda de unnuevo tipo de aplicaciones y soluciones diseñadas específicamente para soportar y hacer uso de ODF.

Palabras clave: aplicaciones ofimáticas, ECMA, estándar abierto, formato de documento, formato defichero, OASIS, ODF, Office Open XML, OpenDocument XML.

Autores

Erwin Tenhumberg es miembro del Grupo de Código Abierto de Sun Microsystems, dirigido por eldirector jefe de código abierto de Sun, Simon Phipps. Se encarga, entre otras cosas, del desarrollo de lacomunidad y de las actividades de marketing para OpenOffice.org. Además, Erwin está especializado enmodelos comerciales de código abierto y código abierto para el sector público. Aparte de su papel en elGrupo de Código Abierto, co-preside el Comité Técnico de Adopción de ODF de OASIS (OpenDocumentFormat Adoption TC). Como parte de su trabajo, Erwin participa activamente en diferentes iniciativasODF como en el estado de Massachusetts en los EEUU o en la Unión Europea. Colabora también con elComité Técnico de OASIS OpenDocument Format, la ODF Alliance y la comunidad de código abiertoOpenOffice.org.

Donald Harbison preside el Comité Técnico de Adopción de ODF de OASIS junto con Erwin Tenhumberg.Donald lleva 10 años en IBM y más de 25 años en la industria del software. Tiene una dilatada experien-cia en la industria de desarrollo de software, en publicaciones técnicas, gestión de documentos y con-tenido, servicios colaborativos como mensajería empresarial y servicios de comunicación con aplica-ciones orientadas a objetos. Además de todas estas responsabilidades, Donald fue miembro del equipode estrategia básica que diseñó y dirigió el desarrollo y ejecución de la estrategia middelware Linux deIBM desde 1998 hasta 2004. En la actualidad es director del programa Nuevos Estándares en el IBMSoftware Group.

Rob Weir es un veterano con 16 años de experiencia en IBM y Lotus Development Corporation. Cuentacon una dilatada experiencia trabajando con formatos ofimáticos, desde los viejos formatos binarios deLotus SmartSuite y Microsoft Office, hasta la nueva generación de formatos XML sometidos a normali-zación. Es miembro del Comité Técnico de Adopción de ODF de OASIS y de los subcomités de metadatos y fórmulas. También es delegado de los EE.UU para ISO/IEC JTC1 SC34.

OASIS (Organization for the Advancement of Structured Information Standards) es un consorcio inter-nacional sin ánimo de lucro que promueve el desarrollo, convergencia y adopción de estándares decomercio electrónico. Sus propios miembros son quienes determinan la agenda técnica de OASIS me-diante un proceso abierto y ágil especialmente diseñado para impulsar el consenso de la industria yaunar esfuerzos dispersos. Este consorcio crea estándares abiertos para servicios web, seguridad,comercio electrónico e iniciativas de estandarización tanto para el sector público como para aplicacio-nes específicas. OASIS fue fundado en 1993 <http://www.oasis.open.org>.

novática nº 184 noviembre-diciembre 2006 7

Formato de Documento Abierto (ODF) monografía

monografía

participar en este ecosistema. Por ejemplo, elestándar SQL para bases de datosrelacionales permitió la aparición de variasimplementaciones, entre las que se encuen-tran sistemas de gestión de bases de datosespecializadas de gran capacidad, gratuitasy de código abierto. Mientras sólo se utilicencaracterísticas del estándar SQL, los datosalmacenados en los sistemas de gestión debases de datos pueden intercambiarse sindemasiado esfuerzo. Un usuario puede ele-gir una implementación SQL que incluyaelementos únicos, específicos del fabricante,además de los básicos, pero al fin y al caboes decisión suya. De esta forma, depender deun solo fabricante es una decisión personal,no una necesidad inevitable.

2. Aprobado por OASIS e ISO: Sinop-sis de ODFEl Formato de Documento Abierto(OpenDocument Format u ODF) es un for-mato de archivo abierto basado en XML paraaplicaciones ofimáticas destinadas a la crea-ción y edición de documentos que contienentexto, hojas de cálculo, gráficas y otros elemen-tos gráficos. Este formato de archivo facilita latransformación a otros formatos al recuperar yreutilizar los estándares existentes siempre quesea posible.

ODF se define a través de un proceso abiertoy transparente en OASIS (Organization forthe Advancement of Structured InformationStandards) y fue aprobado en mayo de 2006de forma unánime por el Joint TechnicalCommittee 1 (JTC1) de la OrganizaciónInternacional para la Normalización(International Organization forStandardization, ISO) y la Comisión Elec-trotécnica Internacional (InternationalElectrotechnical Commission, IEC) comoNorma Internacional. En noviembre de 2006,ISO/IEC anunciaron la publicación y dispo-nibilidad de ISO/IEC 26300:2006. Está dis-ponible para su implementación y uso librede licencia, royalties u otras restricciones.

Al proporcionar tecnologías alternativas alas propietarias, OpenDocument permite alos usuarios finales afrontar la gestión de susdocumentos más importantes con estándaresabiertos. Permite garantizar que los usua-rios finales, como los gobiernos y sus ciuda-danos, sean capaces de acceder a la informa-ción y compartirla, ahora y en el futuro, sintener que seguir pagando gastos innecesa-rios de licencias para poder ver o editarinformación almacenada en formatos pro-pietarios.

Tanto organizaciones como individuos pue-den utilizar cualquier aplicación para el pro-cesamiento de texto, lo que les permite unmayor control de sus documentos al desaco-plar los formatos de los archivos de lasaplicaciones utilizadas para crearlos, espe-

cialmente los formatos propietarios con laslimitaciones y restricciones que conllevan.

OpenDocument promueve la recuperaciónde información a largo plazo al confiar elformato a un cuerpo de estándares indepen-dientes que actúa como una comunidad,contrastando con el hasta ahora monopoliode un solo fabricante, en el que la compati-bilidad de formato de forma regresiva no hasido garantizado. La adopción deOpenDocument evita depender de la vidaútil de un producto de software para mante-ner el acceso a información esencial. La-mentablemente, la experiencia ha demostra-do que la vida útil de una aplicación desoftware sólo cubre una pequeña fracción dela vida útil de documentos de gran importan-cia, como certificados de nacimiento o regis-tros de contabilidad.

En términos técnicos, la especificaciónOpenDocument define un esquema XMLpara aplicaciones ofimáticas así como susemántica. El esquema está diseñado paraque sea compatible con toda una serie dedocumentos ofimáticos como documentosde texto, presentaciones con gráficas, dibu-jos o animaciones, y hojas de cálculo paracálculos financieros, así como acceso a con-juntos de datos externos. El esquema cubrelas necesidades de información de alto nivelal permitir la edición interactiva de los datosdel documento. Define estructuras XML desoporte para toda una serie de documentosofimáticos y puede transformarse fácilmen-te con XSLT o cualquier otra herramientasimilar basada en XML.

La especificación ODF describe la estructu-ra de documentos, los metadatos que pue-den almacenarse en estos documentos, elcontenido de texto y párrafos, los campos detexto, los índices, el contenido de tablas, deimágenes, de gráficas y de formularios, elcontenido común a todos los tipos de docu-mentos, la integración del contenido etique-tado de animación SMIL (SynchronizedMultimedia Integration Language))))), infor-mación de estilo, propiedades de formatoutilizadas en estilos, así como tipos de datosutilizados por el esquema OpenDocument.Es completo, plenamente desarrollado, sim-ple y elegante, y está diseñado para que seaimplementado y soportado por diversos fa-bricantes que satisfagan las necesidades denumerosos clientes.

Desde el punto de vista del empaquetado,ODF es un archivo ZIP que contiene unconjunto de archivos XML que describen elcontenido y el formato del documento. Losarchivos binarios sólo se utilizan para ele-mentos tales como las imágenes insertadas.El uso de XML hace que el acceso al conte-nido del documento sea sencillo, ya que éstepuede abrirse y modificarse con simples edi-

tores de texto en caso necesario. Por el con-trario, los formatos propietarios sólo binariosque se utilizaban antes eran crípticos y difí-ciles de procesar.

La compresión en ZIP garantiza unos tama-ños de archivo relativamente pequeños, loque reduce las necesidades de almacena-miento de archivos y ancho de banda para sutransmisión, lo que también contribuye auna mayor facilidad para el intercambio dearchivos, independientemente del ancho debanda. ODF fue el primer formato de archi-vo utilizado ampliamente que utilizaba unpaquete ZIP con diferentes archivos XML.ODF utiliza el mismo conjunto de archivosXML para tipos diferentes de aplicaciones.Además, las definiciones, para elementostales como las tablas, son consistentes entodos los tipos de aplicaciones.

3. Una larga tradición de apertu-ra: la historia de ODFOpenDocument cuenta con una larga tradi-ción de apertura. Los primeros esfuerzos dedesarrollo de este formato de archivo seremontan a 1999. Desde sus comienzos,ODF fue concebido como un formato dearchivo abierto e independiente de cualquierimplementación.

El proceso de especificación abierta se inicióen 2000 con la fundación del proyecto decódigo abierto OpenOffice.org y los esfuer-zos de la comunidad en el proyecto de desa-rrollo de XML. En 2002 se alcanzó un nivelsi cabe más alto de apertura con la creacióndel Comité Técnico OASIS Open OfficeTechnical Committee.

Durante los últimos siete años, un númerocreciente de organizaciones y empresas se haadherido al proceso de especificación deODF. Además, cada vez más aplicacionesimplementan el formato de archivo OpenDocument. La tabla 1 tabla 1 tabla 1 tabla 1 tabla 1 muestra un resumende la historia del formato OpenDocument.

4. Abierto desde el diseño: losbeneficios de ODFEl Formato de Documento Abierto fue dise-ñado para ser independiente del fabricante yde la implementación. Fue diseñado para serutilizado por el mayor número posible deaplicaciones. Para simplificar las transfor-maciones y maximizar la interoperabilidad,el formato reutiliza estándares establecidoscomo XHTML, SVG, XSL, SMIL, XLink,XForms, MathML y Dublin Core. Los ar-chivos ODF de diferentes tipos de aplicación(p.e. procesador de textos, hoja de cálculo)contienen el mismo conjunto de archivosXML en un paquete ZIP.

La figura 1figura 1figura 1figura 1figura 1 muestra un simple documento detexto en ODF y los contenidos del paqueteZIP correspondiente. La figura 2figura 2figura 2figura 2figura 2 muestra

novática nº 184 noviembre-diciembre 20068

monografía Formato de Documento Abierto (ODF)

monografía

1999 Empieza en StarDivision el desarrollo de un formato de archivo predeterminado en XML. Laslimitaciones de los antiguos formatos binarios y la necesidad de soporte de Unicode desencadenan elcambio. El objetivo es crear un formato de archivo abierto e interoperable que también pueda serutilizado e implementado por otros fabricantes.

Agosto 1999 Sun Microsystems, Inc. adquiere StarDivision.13 de octubre 2000 Sun Microsystems, Inc. publica el código abierto de StarOffice bajo licencias abiertas en el proyecto

OpenOffice.org recientemente fundado (julio 2000).13 de octubre 2000 Se establece en OpenOffice.org el proyecto comunitario XML con el objetivo de definir la especificación

del formato de archivo XML OpenOffice.org como un esfuerzo de la comunidad abierta.2002 Las definiciones para CJK (Chino, Japonés, Coreano) y otros idiomas con representaciones complejas

se añaden a la especificación de formato OpenOffice.org XML.2002 Se inicia la colaboración con el proyecto KOffice.16 de diciembre 2002 El OASIS Open Office Technical Committee convoca su primera conferencia.Mayo 2002 Se publican OpenOffice.org 1.0 y StarOffice 6. Ambos utilizan el formato de archivo OpenOffice.org

XML como formato predeterminado.Agosto 2003 KOffice decide utilizar ODF como formato predeterminado.2003 / 2004 Se modifica la especificación original del formato OpenOffice.org XML para reflejar los últimos

desarrollos en XML y en el área de aplicaciones ofimáticas:* Introducción de espacios de nombre conforme a las reglas de denominación de OASIS.* Cambio de las DTDs de XML a Relax-NG como lenguaje de esquema.* Mejoras en el esquema para soportar mejor la validación de documentos.* Adaptación del esquema para nuevas versiones de estándares.* Adaptación para otras aplicaciones ofimáticas (KOffice).* Adaptación para nuevas versiones de aplicaciones ofimáticas (OpenOffice.org 2.0).* Eliminación de inconsistencias en la especificación.* Corrección de errores.

Diciembre 2004 Se aprueba un segundo borrador del comité, cuyo título cambia de "OASIS Open Office Specification"a "OASIS Open Document Format Office Applications (OpenDocument)".

Enero 2005 El comité técnico cambia de nombre a OASIS Open Document Format for Office Applications(OpenDocument) TC.

Febrero 2005 El tercer borrador de la especificación de formato de archivo, incluyendo las reacciones de laevaluación pública, se aprueba como borrador del comité.

Mayo 2005 El OpenDocument Format (ODF) se aprueba como un estándar de OASIS.Septiembre 2005 Sun Microsystems lanza StarOffice 8 con soporte ODF.Septiembre 2005 ODF se envía a la Organización Internacional para la Normalización (ISO).Septiembre 2005 El INdT (grupo de investigación perteneciente a Nokia) contribuye a ODF con filtros para Abiword y

Gnumeric.Octubre 2005 Se lanza OpenOffice 2.0 con soporte ODF.Octubre 2005 Sun publica la siguiente declaración de convenio de patente:

"La declaración pública de Sun de derechos por falta de afirmación puede resumirse de formaextraoficial como un acuerdo irrevocable para no aplicar ninguna de las patentes aplicables tanto deEE.UU. como del extranjero contra ninguna implementación de la especificación de OASISOpenDocument". <http://xml.coverpages.org/ni2005-10-04-a.html>.

Diciembre 2005 Softmaker lanza Textmaker 2006 con soporte ODF.Enero 2006 IBM lanza IBM Workplace con soporte ODF.Marzo 2006 Se funda la ODF Alliance con 35 miembros iniciales para promover ODF en el sector público.Marzo 2006 Se funda el OASIS ODF Adoption TC con el objetivo de educar al mercado sobre el valor de ODF.Abril 2006 Se lanza KOffice 1.5, que utiliza ODF como formato predefinido.Mayo 2006 ISO aprueba ODF como ISO/IEC 26300.Junio 2006 La ODF Alliance ya tiene más de 200 miembros entre los que se incluyen empresas, organizaciones

y ciudades como BBC, Corel EDS, EMC, IBM, Novell, Red Hat, Oracle, Software AG, Sun Microsystems,y la ciudad de Viena.

Septiembre 2006 La segunda edición de ODF 1.0 se completa con cambios editoriales identificados en el proceso derevisión de ISO.

Octubre 2006 Se aprueba ODF 1.1. como Especificación del Comité (Comittee Specification); está pendiente de serenviado para ser sometido a votación como estándar OASIS en enero de 2007. Desarrollo continuo defórmulas, accesibilidad y meta datos planeados para su publicación en 2007 como ODF 1.2. ODFAlliance supera los 300 miembros de más de 40 países.

Tabla 1. La historia de ODF.

Fecha / Período Acontecimiento / Hito

novática nº 184 noviembre-diciembre 2006 9

Formato de Documento Abierto (ODF) monografía

monografía

una sencilla hoja de cálculo en ODF y elcontenido del archivo ZIP. Tanto el docu-mento de texto como la hoja de cálculotienen la misma estructura, es decir, amboscontienen los archivos content.xml, styles.xmly meta.xml. Las figuras 3 y 4 figuras 3 y 4 figuras 3 y 4 figuras 3 y 4 figuras 3 y 4 ilustran que lastablas en un documento de texto se definenmediante los mismos elementos XML quelas tablas en los documentos de la hoja decálculo. Al utilizar el mismo conjunto dearchivos XML en los documentos ODF ydefinir elementos de documento similarescon los mismos elementos XML para losdiferentes tipos de aplicaciones, la transfor-mación y procesamiento de documentosODF es más sencilla.

La figura 3figura 3figura 3figura 3figura 3 muestra el archivo content.xmlcon una definición de tabla de un documen-to de texto. La figura 4 figura 4 figura 4 figura 4 figura 4 muestra una defini-ción de tabla de un documento de hoja decálculo. Se utilizan los mismos elementosXML para definir las tablas en los documen-tos de hoja de cálculo y los documentos detexto. La tabla 2tabla 2tabla 2tabla 2tabla 2 destaca las característicasprincipales y las ventajas del formatoOpenDocument.

5. Oportunidades de innovación5.1. Integración mediante programa-ción

En la actualidad, programar con datos dedocumentos es demasiado complejo y de-pende de una plataforma. El software deMicrosoft® Office requiere que los desar-rolladores utilicen Microsoft Visual Basicpara aplicaciones, o Visual Studio Toolspara Microsoft Office (ahora en su segundaedición). Ambos entornos sólo soportan soft-ware propietario de Microsoft Windows® yMicrosoft Office. De forma alternativa, losdesarrolladores que trabajan con StarOfficeu OpenOffice deben confiar en la interfaz deprogramación de aplicaciones de UniversalNetwork Objects (UNO), que sólo está dis-ponible en las aplicaciones que acompañana los paquetes ofimáticos correspondientes,como por ejemplo Writer, Calc o Impress,pero que es soportada además por numero-sos sistemas operativos que a su vez sopor-tan múltiples lenguajes de programacióncomo C++, Python, etc. Sin embargo, nin-guna de estas tecnologías interopera biencon tecnologías de terceras partes desarro-lladas independientemente, en el sentido deestándares abiertos de Internet, por ejemploHTML, CSS, Dom y JavaScript.

El Document Object Model (DOM) utiliza-do por todas las aplicaciones modernas denavegadores web es una forma eficaz deintegrar funcionalmente (y no sólo

visualmente) varios tipos de documentos.Asimismo, se utiliza ampliamente en aplica-ciones web de servidor en lenguajes comoJava™. Así pues, es una de las pocas interfacesconocidas y entendidas por programadoresde navegadores basados en scripts así comopor programadores tradicionales que utili-zan lenguajes procedurales como Java.

Ahora mismo, está surgiendo un nuevo mo-delo simplificado de programación basadoen DOM para ODF. Éste reutiliza el formatoODF XML, aunque lo más significativo esque utiliza un DOM como modelo del tiem-po de ejecución del documento. Esto signifi-ca que ahora es posible controlar dinámi-camente un documento ODF utilizando unavariedad de scripts y otros lenguajes. Tam-bién es posible integrar mediante programa-ción el comportamiento de tiempo de ejecu-ción de un documento ODF con otros docu-mentos de estándar abierto basados en DOMcomo XForms y Scalable Vector Graphics(SVG). Y todas las tecnologías basadas ennavega-dores como Cascading Style Sheets(CSS) pueden reutilizarse para la persona-lización y accesibilidad. Además, con unformato realmente abierto que tenga accesoabierto a los elementos de los documentos atodos los niveles, la accesibilidad se convier-te en abierta y programable y deja de estar

unz ip

Figura 1. Un documento de texto ODF sin descomprimir.

unzip

Figura 2. Un documento de hoja de cálculo ODF sin decomprimir.

novática nº 184 noviembre-diciembre 200610

monografía Formato de Documento Abierto (ODF)

monografía

limitada por la realización estática de políti-cas predeterminadas. Esto posibilitará quelos documentos ODF participen y contribuyanen un amplio ecosistema de documentos, y queproporcionen una experiencia enriquecida alusuario a través de la composición sencilla yabierta de elementos estándares.

5.2. Colaboración en torno a docu-mentosHay una tendencia cada vez mayor haciauna fértil colaboración online basada endocumentos. Google Docs and Spreadsheets,Zoho Writer, ajaxWrite y startups de redessociales y gestión de contenido como Zimbra,Socialtext y Alfresco se mueven en esta direc-ción. Antes, los sistemas comerciales de pro-cesamiento de documentos, como el soft-ware Microsoft Office o IBM LotusSmartSuite®, sólo soportaban algunas for-mas de colaboración.

En la actualidad, los wikis y los blogs estánempezando a representar nuevas formas decolaboración en la conocida como platafor-ma "Web 2.0". Sin embargo, los wikis y losblogs no cuentan con un modelo de informa-ción estructurado en su base. Sin esta base,

es difícil soportar el control de acceso basa-do en el contenido, historiales, versiones,vistas y colaboración en directo.

Acoplado con esta tecnología de integra-ción, el modelo de documento ODF basadoen XML puede desencadenar nuevos para-digmas en la colaboración basada en docu-mentos en la web. Éste facilita que múltiplesautores interactúen en tiempo real con eldocumento y su información, permitiendoun control de acceso basado en roles, vistas,versiones e historial. Si combinamos esteconcepto con plantillas específicas para do-cumentos, hojas de cálculo y presentacio-nes, el modelo de ciclo de vida de un docu-mento evoluciona para ser un modelo en elque la interacción y la colaboración sobre elcontenido o la información (datos) en elcontexto de documentos empresariales esradicalmente diferente.

Por ejemplo, un equipo de autores puedereunirse fácilmente a través de la red paraeditar sus documentos en tiempo real utili-zando su(s) editor(es) ODF bajo cualquiercombinación. O simplemente puede editardentro del navegador web. Para facilitar la

edición, el documento ODF es tratado comoun modelo de datos compartidos y se "pre-senta" de formas diferentes: una que es laque usa el editor de ODF nativo y otra enHTML para el editor de texto enriquecido.

Las modificaciones del contenido fluyen enambas direcciones y los usuarios puedencolaborar de forma productiva en el conteni-do, liberado del formato del documento.Esto es posible gracias a que los estándaresabiertos se desarrollan y especifican con laayuda y contribuciones de stakeholders (gru-pos de interés) en una comunidad abierta. Elproceso de estándares abiertos desempeñaun papel importante. Conforme losestándares se definen y evolucionan, losdesarrolladores reconocen cada vez más laoportunidad de nuevos mercados para estasherramientas y tiempos de trabajo. Con estarevolución en el ámbito de estándares dedocumentos abiertos, los líderes de la indus-tria prepararán el camino hacia la colabora-ción basada en el contenido entre diferentestipos de usuarios, editores y dispositivos. Setrata del mismo fenómeno que aceleró eldesarrollo de Internet y su adopción consi-guiente en el comercio y la vida cotidiana.

Figura 3. Archivo content.xml de un documento de texto abierto con Mozilla Firefox.

Figura 4. Archivo content.xml de un documento de hoja de cálculo abierto con Mozilla Firefox.

novática nº 184 noviembre-diciembre 2006 11

Formato de Documento Abierto (ODF) monografía

monografía

5.3. Implicaciones para sistemas degestión de contenido y documenta-ción empresarialLas soluciones actuales para la gestión decontenido y documentación empresarial ges-tionan grandes depósitos de todo tipo dedocumentos informativos, imágenes ymultimedia. Sectores como el bancario y losseguros dependen de estos sistemas paraprocesos empresariales críticos como el pro-cesamiento de reclamaciones o la aproba-ción de créditos. La información empresa-rial no siempre se muestra en formulariosestructurados legibles de forma automática;a menudo existen plantillas semiestruc-turadas, como documentos de reclamacióno solicitudes de préstamo. La informacióndel documento ha de ser indexada para po-der ser buscada de forma eficiente. La tecno-logía de indexación suele depender del nivelde metadatos asociados al documento, yaque los motores de búsqueda se enfrentan alreto de rastrear y recuperar información sig-nificativa cuando las propiedades internasde un documento o imagen se esconden enformato binario.

Con el advenimiento y la adopción anticipa-da a gran escala de ODF, y con la visión defuturo de que los datos de los documentosestarán almacenados en formato XML, es-tos sistemas serán mucho más efectivos conrespecto a su habilidad para indexar, consul-tar, buscar, recuperar y ensamblar medianteoperaciones de transformación nuevos do-cumentos compuestos. Estas nuevas técni-cas y métodos abren nuevos horizontes paradesarrollar soluciones empresariales que sedistinguen claramente del modelo de con-junto de aplicaciones ofimáticas del pasado.De manera más significativa, crean una opor-tunidad para el desarrollo de nuevo softwareque cubrirá con programas muchas fuentesdiferentes de datos en un nuevo documento,automatizando aún más los procesos em-presariales y abriendo nuevos caminos en elrendimiento.Un formato de estándares abiertos es funda-mental porque permite la creación de opera-dores relacionales o del tipo XQuery en undocumento, además de garantizar la semán-tica del mismo. Por ejemplo, en una empresade seguros podrían seleccionarse todos los

documentos de reclamación en los que éstafuera de aproximadamente 20.000 dólares, ofusionar un conjunto de documentos dereclamaciones de automóvil y de viviendapara crear un documento con el importe dela reclamación, el tipo de reclamación y elnombre del cliente, y después recopilar elnuevo documento compuesto de inmediato.

De hecho, los sistemas de gestión de docu-mentos pueden disponer de motores de mini-búsqueda (minisearch ) y de minería de rela-ciones (relationship mining) y proponer nue-vos enlaces entre proyectos o activos enorganizaciones, así como contribuir al ren-dimiento total de la empresa.

6. El futuro del estándar OpenDocumentEs importante indicar que, hoy por hoy,ODF está disponible en su primera versión.Como estándar abierto de derecho, el desa-rrollo y responsabilidad de la especificaciónODF continúa en OASIS, y son muchos losfabricantes y personas de organizacionesdiversas los que colaboran y lideran la inicia-

Tabla 2. Ventajas de ODF.

Estándar OASIS Proceso de especificación abierto y transparente con participación de numero-sos fabricantes.

Aprobado por ISO como ISO/IEC 26300. Estándar conocido y ampliamente aceptado.Tipos de esquema Relax-NG, estándar ISO(ISO/IEC 19757-2:2003). Estándar conocido y ampliamente aceptado.Soporte por parte de numerosas aplicaciones Elección entre implementaciones gratuitas, de código abierto y comerciales,

entre las que se encuentran OpenOffice.org, StarOffice, KOffice, IBM Workplace,Textmaker, Abiword/Gnumeric, Google Docs & Spreadsheet y AjaxWrite.

Amplio apoyo por parte de la industria ODF garantiza la viabilidad a largo plazo. El OASIS ODF TC, el OASIS ODFAdoption TC, y la ODF Alliance cuentan con miembros de Adobe, BBC, BristolCity Council, Bull, Corel, EDS, EMC, GNOME, IBM, Intel, KDE, MySQL AB,Novell, Oracle, Red Hat, Software AG, Sun Microsystems y la ciudad de Viena.En diciembre de 2006, la ODF Alliance contaba ya con más de 350 miembros.

Distribución de productos desdeseptiembre de 2005 Ya pueden crearse y utilizarse archivos ODF. Los primeros productos con

soporte ODF empezaron a distribuirse en septiembre de 2005.Implementaciones de "referencia"gratuitas de código abierto. Numerosas aplicaciones gratuitas de código abierto, entre las que se encuen-

tran OpenOffice.org, KOffice y Abiword Gnumeric, soportan ODF.OpenOffice.org, por ejemplo, ha sido desarrollado por una gran comunidad queincluye fabricantes como Sun Microsystems, Novell, Intel y Red Hat. Como elcódigo abierto está disponible, cualquiera puede ofrecer soporte para otrasplataformas.

Las implementaciones ODF están disponiblespara todas las plataformas de escritorio Hay aplicaciones con soporte ODF disponibles para Microsoft Windows, Linux,

el sistema operativo Solaris, Apple Mac OS X, y FreeBSD.La tecnología de estándar abierto W3CXForms se utiliza para formularios El concepto de formulario integrado en ODF está basado en el estándar W3C

XForms, soportado por un gran número de aplicaciones y fabricantes.Reutilización de estándares existentessiempre que sea posible Para simplificar la interoperabilidad lo máximo posible, ODF reutiliza estándares

establecidos, como XHTML, SVG, XSL, SMIL, XLink, XForms, MathML y DublinCore.

Bien establecido Los primeros esfuerzos de desarrollo del formato de archivo ODF empezaronen 1999 (ver la historia de ODF en la tabla 1).

Característica Ventaja

novática nº 184 noviembre-diciembre 200612

monografía Formato de Documento Abierto (ODF)

monografía

tiva. Antes de finales de 2006 concluirá unaparte importante del nuevo trabajo de tressubcomités. Éste será sometido a voto comoestándar abierto y pasará por procesos derevisión pública, lo que resultará en unaactualización de ISO/IEC 26300:2006 en lasegunda mitad de 2007.

La especificación ODF se actualizará conextensiones sobre accesibilidad, metadatosy nuevas fórmulas y se continuará apoyandouna continua innovación creativa. Así pues,ahora sólo estamos asistiendo al estreno dela especificación, pero se espera mucho másen un futuro muy cercano.

Un estándar abierto, bajo la responsabilidadde numerosos fabricantes en un consorciobona fide de estándares abiertos garantizaque la tecnología evolucionará y continuarágenerando valor durante los próximos años.

6.1. Veinte cosas que pueden hacersecon el formato OpenDocumentRob Weir enumera una variedad de modelosde uso para ODF, demostrando que tieneuna amplia aplicación que va más allá de loofrecido por los sofisticados editores tradi-cionales de oficina. Lo incluimos aquí paraestimular la imaginación y la curiosidad denuestros lectores.

1. Creación interactiva en una aplicacióncliente sofisticada. Esta es el forma tra-dicional de trabajar en KOffice, OpenOffice.org, etc.

2. Creación interactiva en una aplicaciónweb ligera. Estamos empezando a verloen Google Docs Spreadsheets.

3. Autoría en colaboración (múltiples au-tores). Incluye el tradicional estilo "co-menta y fusiona" de colaboración asícomo la edición en tiempo real por partede varios usuarios, donde varios autoreseditan el mismo documento de formasimultánea.

4. Creación automática de documentos enrespuesta a una consulta a una base dedatos. Se trata del modelo de uso degeneración de informes. Más que unabase de datos, el origen de los datospodría ser un servicio web.

5. Indexación/escaneado de documentospara el motor de búsqueda.

6. Escaneado por parte del anti-virus.7. Otros tipos de escaneado, posiblemente

de acuerdo con regulaciones, fines lega-les o forenses.

8. Validación de un documento con respec-to a especificaciones, guías de estilo in-ternas, prácticas de accesibilidad etc. Estova más allá de la validación RELAX NG,más allá de Schematron, hacia una vali-dación de contenido que va más allá de laestructura XML.

9. Presentación sólo en lectura de docu-mentos en la máquina sin el editor com-

pleto, por ejemplo en un visor ligero através de un plug-in o extensión en elnavegador.

10. Conversión de documentos de un forma-to editable a otro, p.e. convertir ODF aOOXML.

11. Conversión de un documento a formatopresentación, como PDF, PS, print o fax.

12. Presentar un documento a través de otrosmodos como sonido o video (síntesis delhabla).

13. Reducción/simplificación del documen-to para presentarlo en un dispositivosub-desktop como un teléfono móvil oPDA.

14. Importar ODF a una aplicación noofimática, por ejemplo, importar datosde una hoja de cálculo a un software deanálisis estadístico.

15. Exportar de una aplicación no ofimáticaa ODF, por ejemplo, exportar datos deuna aplicación de contabilidad personala una hoja de datos.

16. Una aplicación que toma un documentoexistente y produce una versión modifi-cada de la presentación, p.e. rellena unaplantilla, traduce el idioma etc. Esto tie-ne algunas ventajas interesantes, ya quepermite la separación de intereses, deforma que un usuario puede controlar elaspecto del documento, mientras que loshuecos pueden rellenarse de forma auto-mática, basados por ejemplo en la con-sulta a un servicio web.

17. Agregar o verificar las firmas de un docu-mento para controlar el acceso (DRM)

18. Software que utiliza documentos comoparte de un workflow, pero tratándoloscomo una caja negra o en todo caso sóloteniendo en cuenta metadatos básicos.De esta forma trabajan la mayoría de lossistemas actuales.

19. Software que trata los documentos comoparte de un workflow y es capaz de ins-peccionar el documento y tomar decisio-nes basadas en el contenido. Esto esposible gracias a la transparencia delformato ODF y a la capacidad del soft-ware de ver lo que hay en el interior.

20. Software que comprime y descomprimeun documento en un formulario de basede datos relacional, p.e. XML-RelationalMapping.

7. ResumenLa historia ha demostrado que la adopciónde estándares comunes hace que la sociedadconsiga resultados fuera de lo común. Lanormalización en la electricidad, los siste-mas de cambio de trenes, el equipamiento deemergencia de bomberos o en el ámbitonaval han transformado nuestro planeta.Internet, basada en la amplia participación ydisponibilidad de especificaciones estándar,ha representado una puerta abierta en lavida de muchas personas y ha creado opor-tunidades ilimitadas de crecimiento, explo-

[1] OASIS Accessibility Guidelines forImplementations of OpenDocument Format v1.1.<http://www.oasis-open.org/committees/download.php/20977ODF_Accessibility_ Guidelines_14_2Nov06.odt>.Página principal del OASIS Open Document FormatTC. <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office>.Página principal del OASIS OpenDocument FormatAccessibility Sub Committee. <http://www.oasis-open.org/committees/tc_home.php? wg_abbrev=office-accessibility>.Página principal del OASIS OpenDocument FormatMeta Data Sub Committee. <http://www.oasis-open.org/committees/tc_home.php? wg_abbrev=office-metadata>.Página principal del OASIS OpenDocument FormatFormula Sub Committee. <http://www.oasis-open.org/committees/tc_home.php? wg_abbrev=office-formula>.Página principal del OASIS ODF Adoption TC. <http://www.oasis-open.org/committees/tc_home. php?wg_abbrev=odf-adoption>.Sitio web con información sobre ODF. <http://www.opendocument.xml.org>.Página pricipal de la ODF Alliance. <http://www.odfalliance.org/about.php>.Página de Wikipedia sobre ODF. <http://en .w ik iped ia .o rg /w ik i /OpenDocumen t>.Libro online: OASIS OpenDocument Essentials.<http://books.evc-cit.info/>.Módulo de Perl para ODF. <http://search. cpan.org/dist/OpenOffice-OODoc/>.

Referencias

ración e innovación, generando un valormucho mayor de lo que un solo fabricantepueda ser capaz. Como se ve reflejado enesta experiencia, los estándares abiertos pro-porcionan ventajas fundamentales en áreascomo:

innovación en colaboracióninnovación en colaboracióninnovación en colaboracióninnovación en colaboracióninnovación en colaboración: comunida-des de organizaciones, gobiernos e indivi-duales se reúnen para enfrentarse a gravesproblemas como proporcionar remedios trasun desastre natural.

flexibilidadflexibilidadflexibilidadflexibilidadflexibilidad: los estándares proporcionanmás opciones tecnológicas para los ciuda-danos, usuarios e implementadores para con-figurar de forma sencilla sistemas de infor-mación, adquirir tecnología de un mercadocompetitivo y adaptarse más fácilmente a losrequisitos y procedimientos en continuo de-sarrollo.

interoperabilidad:interoperabilidad:interoperabilidad:interoperabilidad:interoperabilidad: eliminando las barrerasque ponen freno a la comunicación ycompartición de información, en y entre go-biernos, especialmente en temas de salud,seguridad pública y educación.

coste-efectividadcoste-efectividadcoste-efectividadcoste-efectividadcoste-efectividad: donde las políticas deadopción a favor de los estándares abiertosno permiten el bloqueo por parte de un solofabricante e incrementan la elección compe-titiva mientras bajan los precios.

libertad de acciónlibertad de acciónlibertad de acciónlibertad de acciónlibertad de acción: que permite a los usua-rios beneficiarse de un "terreno de juegonivelado", disminuyendo el riesgo de que unsolo vendedor controle o bloquee la tecnolo-gía.

novática nº 184 noviembre-diciembre 2006 13

Formato de Documento Abierto (ODF) monografía

monografía

1. IntroducciónDesde que el estándar OpenDocument fueratificado por OASIS (Organization for theAdvancement of Structured InformationStandards) en mayo de 2005, ha ido adqui-riendo fuerza. En mayo de 2006 la ISO(International Organization forStandardization) aprobó formalmente unborrador del estándar ISO/IEC 26300OpenDocument [1]. KOffice está comple-tando su cambio a OpenDocument comoformato nativo (OpenOffice lo hizo hacetiempo), y se anuncian nuevas imple-mentaciones cada mes. Massachusetts hacontinuado su plan de cambio a pesar dealgunos asuntos políticos turbios, y todaslas evidencias sugieren un uso creciente anivel mundial. El artículo sobre OpenDocument en Wikipedia [2] ofrece más in-formación, incluyendo el proceso de adop-ción de OpenDocument [3].

Pero, ¿es verdaderamente OpenDocumentun estándar abierto, o no? Por ejemplo,¿puede implementarlo cualquiera? ¿Fue suproceso de desarrollo controlado de formapartidaria (lo que significaría "no abierta"),o hay evidencia de que es resultado de unconsenso de muchos? Generalmente, se acep-ta que OpenDocument es un estándar abier-to, pero recientemente se ha oído a gente quedice cosas diferentes. Definamos entoncescuáles son los criterios para un estándarabierto y veamos si OpenDocument cumpleesos criterios.

2. ¿Qué es un estándar abierto?No hay una definición simple para "estándarabierto". En realidad, esto suele ser ciertopara muchas palabras y frases. Existen mu-chos documentos que esbozan lo que signi-fica, por ejemplo:

El informe europeo Valoris [4] define unestándar abierto de la siguiente forma: "Losrequerimientos mínimos para un estándarabierto son que el formato del documentoesté completamente descrito en documen-tos accesibles públicamente, que esta des-cripción pueda ser distribuida públicamentey que el formato del documento pueda serimplementado en cualquier programa sinrestricciones, libre de derechos, y sin limita-ciones legales".

En un trabajo previo [5] escribí que "cuan-do pensamos en ‘abierto’, pensamos en ‘com-petición abierta’ o en ‘mercado abierto’. Unestándar abierto debe permitir la competen-

cia basada en el mérito, en lugar de limitarlos proveedores de los consumidores a unoen particular, o a un conjunto de ellos, basa-dos en modelos de negocio, desarrollo, li-cencia u otros. Debería permitir reemplazarun producto por otro que haga la mismafunción, en tanto siga el estándar abierto, ycumpla, como mínimo, la misma funciónbásica ofrecida por el estándar (aunque al-gunos pueden comportarse mejor u ofrecercaracterísticas adicionales – pensemos encomponentes reemplazables)".

Veamos ahora las dos definiciones de"estándar abierto" que parecen ser las másampliamente usadas. La primera es de BrucePerens; la segunda es de Ken Krechmer(miembro del International Center forStandards Research). Las dos son tan am-pliamente utilizadas que cuando hacemosuna búsqueda en Google para "openstandards" aparecen en los primeros luga-res. (Los otros son ocupados por OASIS y elW3C, dos organizaciones que desarrollanestándares abiertos). Después revisaremosla definición de estándares abiertos de laComisión Europea, que es una definicióndel término oficialmente aprobada (y queutilizan los gobiernos europeos).

Más tarde, después de revisar las tres defini-ciones, crearemos una definición combina-

da que incluya todos los requerimientos (delas tres fuentes). De esta forma, si la especi-ficación cumple esta combinación, podre-mos confiar en que tenemos un estándarabierto puesto que la especificación cumpli-ría con las tres definiciones completas.

2.1. PerensUna definición muy popular del término"estándares abiertos" (la más popular segúnGoogle) es la que ofrece Bruce Perens en"Open Standards: Principles and Practice"[6]. Les recomiendo que lean el documentocompleto, por supuesto. Y permítanme re-sumirlo en una lista de los principios queestablece para que una especificación puedaser un estándar abierto:1. Disponibilidad: los estándares abiertos

están disponibles para que cualquiera loslea y los implemente.

2. Maximizar la elección del usuario final:los estándares abiertos crean un mercadojusto y competitivo para las implemen-taciones del estándar. No bloquean al usua-rio en un vendedor o grupo único.

3. Sin pago de derechos: los estándares abier-tos son gratuitos para cualquiera que losimplemente, sin derechos ni tasas. La cer-tificación del cumplimiento de losestándares por una agencia de estandari-zación sí puede incluir un pago.

4. Sin discriminación: los estándares abier-

¿Es OpenDocumentun estándar abierto?: ¡Sí!

David A. WheelerPresidente del OASIS ODF FormulaSubcommittee

<dwheeler@dwheeler.com><dwheeler@dwheeler.com><dwheeler@dwheeler.com><dwheeler@dwheeler.com><dwheeler@dwheeler.com>

Traducción: Traducción: Traducción: Traducción: Traducción: Jesús Tramullas Saz (Universidad de Zaragoza).

Resumen: este trabajo demuestra que OpenDocument es un verdadero formato abierto. Identifica lasdefiniciones más importantes del término "estándar abierto", y combina sus requerimientos para crearuna definición más completa, demostrando que OpenDocument cumple estrictamente todos los re-querimientos. En particular, el análisis se centra en las cuestiones referidas a la "No discriminación" y"No dominación", requisitos en los que fallan otras especificaciones, pero que OpenDocument sí satis-face.

Palabras clave: discriminación, dominación, estándar abierto, formato abierto, interoperabilidad,Krechmer, OpenDocument, Perens, Unión Europea.

Autor

David A. Wheeler ha trabajado largo tiempo en la mejora de software y es un experto en seguridadinformática, software libre y de código abierto y estándares abiertos. Sus publicaciones incluyen loslibros "Secure Programming for Linux and Unix HOWTO" y "Software Inspection: An Industry Best Practice"(IEEE Computer Society Press), el espacio "Secure Programmer" en la publicación digital developerWorksy los artículos "Countering Trusting Trust through Diverse Double-Compiling (DDC)" y "Why OSS/FS?Look at the Numbers!". Quedó tan impresionado con OpenDocument que después de que OASIS com-pletase OpenDocument 1.0, se unió a la organización, y ahora lidera el Subcomité de Fórmulas en OASISODF. Su sitio web se encuentra en <http://www.dwheeler.com>.

David A. Wheeler, 2006. Este artículo se distribuye bajo la licencia "Attribution-NonCommercial 2.0" de Creative Commons disponible en <http://creativecommons.org/licenses/by-nc/2.0/>. Fue publicado previamente en Groklaw <http://www.groklaw. net/> y en la web del autor <http://www. dwheeler.com/>.

novática nº 184 noviembre-diciembre 200614

monografía Formato de Documento Abierto (ODF)

monografía

tos y las organizaciones que los adminis-tran no pueden favorecer a unimplementador sobre otro por ningunarazón, más que por el cumplimiento de losestándares técnicos de la implementaciónde un vendedor. Las organizaciones decertificación deben proveer una forma devalidar las implementaciones a coste ceroo muy bajo, pero también pueden darservicios de certificación de valor añadi-do.

5. Extensión o subconjuntos: las implemen-taciones de los estándares pueden ser ex-tendidas, u ofrecidas en forma desubconjuntos. Sin embargo, las organiza-ciones de certificación pueden declinar lacertificación de subconjuntos, y puedenhacer requerimientos sobre las extensio-nes (ver "prácticas predatorias").

6. Prácticas predatorias: los estándares abier-tos pueden emplear términos de licenciaque los protejan contra la perversión delestándar mediante técnicas de "adopcióny extensión". Las licencias incorporadas alestándar pueden requerir la publicaciónde la información de referencia de lasextensiones, y una licencia para todos quepermita crear, distribuir y vender softwareque sea compatible con dichas extensio-nes. Un estándar abierto no puede prohi-bir extensiones de otro modo.

2.2. KrechmerLa otra definición popular es el conjunto de"Requerimientos para estándares abiertos"[7] creados por Ken Krechmer, miembro delInternational Center for Standards Research,University of Colorado. Ha publicado variasversiones; aquí resumiré la del 7 de febrerode 2005. Analiza los estándares desde elpunto de vista de las organizaciones recono-cidas de estandarización, implementadoresy usuarios, y trata de encontrar un puntointermedio en el que coincidan sus deseos.Establece que un estándar abierto debe cum-plir las siguientes condiciones:1. Reuniones abiertas: todos pueden partici-

par en el proceso de desarrollo deestándares.

2. Consenso: se discuten todos los interesesy se consigue un acuerdo, no una domina-ción.

3. Proceso de decisión: se usa la votación y

las propuestas para buscar la resolución.4. Derechos de propiedad intelectual abier-

tos: cómo los poseedores de derechos depropiedad intelectual relacionados con elestándar los hacen disponibles.

5. Mundo único: el mismo estándar para lamisma capacidad, a nivel mundial.

6. Cambio abierto: todos los cambios se pre-sentan y se acuerdan en un foro que sigalos cinco requerimientos previos.

7. Documentos abiertos: los borradores delcomité y los documentos completos de losestándares están disponibles fácilmentepara su implementación y uso.

8. Interfaz abierta: soporte a la ventaja pro-pietaria (implementación); cada interfazno está oculto ni controlado (implemen-tación); cada interfaz de la implementaciónsoporta la migración (uso).

9. Acceso abierto: mecanismos de conformi-dad objetivos para la prueba de implemen-taciones y la evaluación de los usuarios.

10.Soporte continuo: los estándares se so-portan hasta el final del interés del usua-rio, no hasta el final del interés del imple-mentador.

Estas definiciones tienen mucho en común.Krechmer escribió su texto después quePerens, y comparó su lista con la de éste.Identificó cada uno de los seis puntos dePerens, y los equiparó con los suyos segúnpodemos observar en la tabla 1tabla 1tabla 1tabla 1tabla 1.

Sin embargo, la lista de Krechmer tiene suspropios problemas. En particular, omite unode los factores más importantes: la capaci-dad de cada uno para implementar elestándar. La cuestión clave de los estándaresabiertos es permitir que cualquiera imple-mente el estándar, y permitir que cada usua-rio pueda seleccionar libremente y cambiarentre múltiples implementaciones. La listadenota la importancia de las patentes y delos derechos, pero su definición permite quelos estándares abiertos prohíban a sus com-petidores implementar el estándar.

Es un fallo fundamental en esta definición:definir un estándar abierto como un estándarque puede prohibir su implementación aotros competidores es un sinsentido. Estochoca con otros muchos trabajos. La defini-

ción de Perens lo prohíbe expresamente, aligual que el informe Valoris [4], que requierecomo mínimo que el formato "debe serimplementado en programas sin restricción,libre de derechos, y sin limitaciones legales."También entra en conflicto con la definiciónde estándares abiertos de la Comisión Euro-pea, que también requiere uso libre de dere-chos (ver más adelante).

El ejemplo económicamente más obvio deeste conflicto es el software de código abier-to (open source software). Hoy en día, en unvasto número de mercados, el open source esdominante o es el segundo, incluyendo ser-vidores web, navegadores web, servidores decorreo y servidores DNS. Puesto que soft-ware de código abierto tiene legalmente pro-hibido usar trabajos patentados o bajo dere-chos, obviamente las especificaciones querequieren patentes privativas con derechos uotras restricciones legales que impiden elsoftware libre o implementaciones propieta-rias no son estándares abiertos. Un estándarno puede ser "abierto" si es ilegal que seaimplementado por el dominante o por suprincipal competidor.

Este conflicto entre patentes y estándaresabiertos sólo tiene sentido cuando se piensaen él. El propósito de las patentes es prevenirla competencia, mientras que el propósito delos estándares abiertos es permitir la librecompetencia. Estándares abiertos no es lomismo que software de código abierto: po-demos elegir estándares abiertos y usar sólosoftware propietario. Pero seleccionarestándares abiertos nos permite elegir entreimplementaciones, incluyendo código abier-to, y nos permite cambiar de implementaciónmás adelante.

2.3. Comisión EuropeaLa Comisión Europea (CE) ha definido eltérmino "estándares abiertos" como parte dela versión final 1.0 de la EuropeanInteroperability Framework [9]. Newsforgeha publicado un artículo breve sobre ello[10]. La CE declaró que "para alcanzar lainteroperabilidad en el contexto de los servi-cios paneuropeos de gobierno electrónico, laorientación necesita enfocarse hacia losestándares abiertos". Define que viene a con-tinuación como "las características mínimasque una especificación y sus documentosrelacionados deben tener para ser conside-rados un estándar abierto":

El estándar es adoptado y será mantenidopor una organización sin ánimo de lucro, ysu futuro desarrollo se producirá sobre labase de un proceso de decisión abierto atodas las partes interesadas (consenso odecisión mayoritaria, etc.).

El estándar ha sido publicado y el docu-mento de especificación del estándar se en-cuentra disponible libremente, o con un cos-te mínimo. Debe estar permitido a todos

Perens Krechmer Disponibilidad Documentos abiertos Maximizar la elección del usuario final Acceso abierto Sin derechos Derechos de propiedad intelectual abiertos Sin discriminación Reuniones abiertas, Consenso, Proceso de

decisión Extensión o subconjuntos Interfaz abierta Prácticas predatorias Cambio abierto Tabla 1. Equiparación de las definiciones de "estandar abierto" de Perens y Krechmer.

novática nº 184 noviembre-diciembre 2006 15

Formato de Documento Abierto (ODF) monografía

monografía

copiarlo, distribuirlo y usarlo sin coste o a uncoste simbólico.

La propiedad intelectual –por ejemplo lapresencia de posibles patentes—en el (o enpartes del) estándar se hace disponible irre-vocablemente sobre la base de la liberaciónde derechos.

No hay limitaciones para la reutilizacióndel estándar.

El documento también sugiere que el soft-ware de código abierto cumple con losestándares abiertos: "El software open sourcetiende a usar y ayuda a definir estándaresabiertos y especificaciones públicamente dis-ponibles. Los productos open source son,por naturaleza, especificaciones públicamen-te disponibles, y la disponibilidad de su có-digo fuente promueve el debate abierto ydemocrático sobre las especificaciones, ha-ciéndolas más robustas e interoperables.Como tal, el software open source corres-ponde con los objetivos del Framework ydebería ser valorado y considerado favora-blemente frente a alternativas propietarias".Tanto la definición como el texto explicativodejan claro que el intento es que cada estándarabierto debe ser implementable tanto porsoftware open source como por programaspropietarios, especialmente dados sus re-querimientos de uso libre de derechos y defalta de restricciones de reutilización.

2.4. Mezclando las definicionesUsemos una definición de "estándar abierto"mezclando lo mejor de cada una, y que unaespecificación debiera cumplir para califi-carse como tal. Si comparamos las listas deKrechmer y de Perens, esta última es máscorta, clara y no tiene el serio defecto de noconsiderar la prohibición de la competencialibre. Añadiremos los dos puntos deKrechmer sobre "mundo único" y "soportecontinuo" marcados como importantes. Lamayoría de los requerimientos de la CE seajustan bien a los de Perens, exceptuandoque el requerimiento de gratuidad o de costemínimo no es explícito (ver tabla 2tabla 2tabla 2tabla 2tabla 2).

De nuevo, añadamos "especificación sin costeo con coste simbólico". Perens no dice explí-citamente que quien mantenga un estándartenga que hacerlo sin ánimo de lucro, perorequiere que no haya discriminación, lo queesencialmente es lo mismo; lo añadiremoscomo un requerimiento implícito a la nodiscriminación.

El resultado es una definición ligeramentemás estricta de "estándar abierto" que cual-quiera de las otras tres por sí mismas. Así,cualquier especificación que cumpla estadefinición mezclada es claramente unestándar abierto..3. ¿Es OpenDocument un estándarabierto?

3.1. Repaso a los requerimientosEntonces, ¿es OpenDocument un estándarabierto? Repasemos la lista de requerimien-tos (editada en cursiva):1.Disponibilidad: los estándares abiertosestán disponibles para cualquiera los lea eimplemente.Esto es sencillo, se puede descargar la especi-ficación OpenDocument libre y gratuitamentede OASIS [12]. Cualquiera puede implementarOpenDocument; si revisamos las condicio-nes de propiedad intelectual establecen cla-ramente que absolutamente cualquiera pue-de hacerlo y que no hay ningún límite.

2.Maximizar la elección del usuario final:los estándares abiertos crean un mercadolimpio y competitivo para las implementaciones del estándar. No bloquean al usua-rio en un vendedor o grupo particular.La cuestión fundamental es determinar sihay múltiples implementaciones disponiblesen múltiples y diferentes plataformas. Larespuesta a esto es enfáticamente sí: haymúltiples implementaciones de OpenDocument, y muchas más en marcha.OpenOffice.org/StarOffice y KOffice sonconjuntos de aplicaciones ofimáticas quepermiten leer y escribir en OpenDocument, y

son completamente independientes. Haymuchos productos especializados queimplementan las partes relevantes, por ejem-plo AbiWord and Writely son proce-sadoresde texto que pueden leer y escribir la parte deprocesado de textos de OpenDocument;Gnumeric es una aplicación de hoja de cál-culo que implementa la definición de hoja decálculo de OpenDocument.Podemos observar aún otras evidencias:a)¿Hay múltiples implementadores implica-dos en la especificación para prevenir unbloqueo? Sí: Sun, KDE, Corel (WordPerfect), IBM (IBM Workplace y LotusSmartSuite) y otros. Discutiremos más so-bre los participantes más adelante.b)¿Hace la especificación una reutilizaciónmáxima de otros estándares abiertos (ya quede otra forma terminaría creando dependen-cias innecesarias de componentes noestándares)? Sí, otros estándares que reutilizason SVG, SMIL, XSL, XForms, MathML,XLink y Dublin Core.

3.Sin derechos: los estándares abiertos sonirrevocablemente libres para todas lasimplementaciones, sin derechos ni pagos.La certificación del cumplimiento por partede la organización de estandarización puedeimplicar un pago.No hay pago ni derechos para implementarOpen Document, por lo que lo cumple al100%.

4.Sin discriminación: los estándares abier-tos y las organizaciones que los administranno favorecen a un implementador sobre todopor ninguna otra razón que no sea que elcumplimiento de los estándares técnicos porparte de la implementación del vendedor.Las organizaciones de certificación debenofrecer una forma de validar lasimplementaciones a coste cero o a bajo cos-te, pero pueden ofrecer servicios de certifica-ción de valor añadido.Creo que esto es un claro "sí", sin embargo esmás difícil medir esto que el resto de lascondiciones. Exploraremos este aspecto se-guidamente, para ver por qué creo que larespuesta es afirmativa.

5.Extensión o subconjuntos: las implemen-taciones de los estándares abiertos puedenextenderse u ofrecerse en forma de subcon-juntos. Sin embargo, las organizaciones decertificación pueden rechazar el certificarimplementaciones de subconjuntos, y pue-den hacer requerimientos sobre las extensio-nes (ver prácticas predatorias).Se pueden implementar subconjuntos osuperconjuntos de OpenDocument sin nin-gún requerimiento especial, por lo que secumple claramente.

6.Protección de prácticas predatorias: losestándares abiertos pueden emplear térmi-nos de licencia que protejan contra la sub-Tabla 2. Equiparación de las definiciones de "estandar abierto" de Perens y la Comisión Europea.

Perens Comisión Europea Sin discriminación El estándar es adoptado y será mantenido por una organización sin

ánimo de lucro, y su futuro desarrollo se producirá sobre la base de un proceso de decisión abierto a todas las partes interesadas (consenso o decisión mayoritaria, etc.).

(sin correspondencia) El estándar ha sido publicado y el documento de especificación del estándar se encuentra disponible libremente, o con un coste mínimo. Debe estar permitido a todos copiarlo, distribuirlo y usarlo sin coste, o a un coste nominal.

Sin derechos La propiedad intelectual –por ejemplo, presencia de posibles patentes-- de (o de partes del) estándar se hace disponible irrevocablemente sobre la base de liberación de derechos

Disponibilidad No hay limitaciones para la reutilización del estándar.

novática nº 184 noviembre-diciembre 200616

monografía Formato de Documento Abierto (ODF)

monografía

versión del estándar mediante técnicas deadopción y extensión. Las licencias asigna-das al estándar pueden requerir la publica-ción de información de referencia para lasextensiones y una licencia para todos los quequieran crear, distribuir y vender softwarecompatible con las extensiones. Un estándarabierto no puede prohibir extensiones deotra forma.Los desarrolladores de Open Document de-cidieron no incluir ninguna medida protec-tora contra subversiones de terceros. Se re-quirió a todos los miembros que crearon elestándar que garantizasen licencias libres dederechos para implementarlo. Esto previnoque nadie insertase sigilosamente un requeri-miento en el estándar y que después de laratificación anunciase que exigiría pago porparte de los implementadores. Este requeri-miento es fácil de cumplir.

7.Mundo único: el mismo estándar debería seraplicable para la misma capacidad en todo elmundo.La especificación OpenDocument fue diseña-da específicamente para ser usada en todo elmundo, sin límite de regiones. Incluye la capa-cidad de soportar conjuntos de caracteres ylenguajes arbitrarios, y de hecho fue desarro-llado por representantes de diferentes países.Por ejemplo, soporta caracteres Unicode/ISO10646 (cuyo propósito es soportar caracteresde todos los lenguajes), texto Ruby (importan-te para algunos lenguajes asiáticos) y textoescrito de derecha a izquierda (como el árabe yel hebreo). Reutilizar otros estándares abiertosayuda. El trabajo para evitar técnicas patentadashace más sencillo que cualquier usuario, encualquier lugar del mundo, pueda usar elestándar (de otra forma, sólo se podría usar elestándar en países que no permitiesen patentesde software). Discutiremos sobre patentes des-pués, ya que las patentes entran en conflictocon el requerimiento previo de no discrimina-ción.

8.Soporte continuo: el estándar es soporta-do hasta que cese el interés del usuario, nohasta que decline el del implementador.OASIS, una organización de estándares,soporta OpenDocument, no un vendedor enparticular. De esta forma, mientras hayausuarios que deseen soportarlo, pueden tra-bajar con OASIS. No hay ningún indicio deque esto sea un problema, hay interés masi-vo en OpenDocument.

9.No hay coste, o este es simbólico:OASIS ha dispuesto la especificación en susede web sin coste, cumpliendo claramenteesta condición.

En resumen, hemos conseguido responder "sí"a todas las condiciones. Sólo una de ellas hasido respondida trivialmente, y es difícil demedir. Me refiero a la "No discriminación". Noes porque haya un problema en OpenDocument

sobre este asunto, es porque es difícil de mediren cualquier estándar. Entremos con más de-talle en esta cuestión para ver si OpenDocumentcumple el requerimiento. Si lo hace entonceses, claramente y sin ningún tipo de ambigüe-dad, un estándar abierto.

3.2. Sin discriminaciónPerens establece que los estándares abiertosdeben serlo "sin discriminación", esto es, que"los estándares abiertos y las organizacionesque los administran no pueden favorecer aun implementador sobre otro por ningunarazón, más que por el cumplimiento de losestándares técnicos de la implementación deun vendedor. Las organizaciones de certifi-cación deben proveer una forma de validarlas implementaciones a coste cero o muybajo, pero también pueden dar servicios decertificación de valor añadido". Con el temade la certificación no hay problema, por lotanto, no lo trataremos más.

La Comisión Europea tiene un requerimientoexplícito de que la organización administrado-ra no debe tener ánimo de lucro, lo que essencillo de demostrar en este caso: OASIS notiene ánimo de lucro. Pero hay más cosas quehacer para evitar la discriminación aparte sim-plemente de crear una especificación a travésde una organización sin ánimo de lucro.

¿Y sobre la primera parte completa del re-querimiento de Perens? Krechmer la hacecorresponder con tres requerimientos:

Reuniones abiertas: todos pueden partici-par en el proceso de desarrollo de estándares.

Consenso: se discuten todos los interesesy se llega a un acuerdo, no a una domina-ción.

Proceso de decisión: se pueden usar vota-ciones y un proceso de apelaciones parabuscar una resolución.

El proceso de decisión es fácilmente com-probable. OpenDocument se desarrolló enOASIS, que tiene claros procedimientos devotación y apelación, por lo que está clara-mente cumplido.

El requerimiento sobre "reuniones abiertas"es un poco más debatible, pero tambiénparece cumplirse, ya que:

No significa que cada uno tenga que partici-par (algunas veces las organizaciones que de-berían no lo hacen). En 2004, Europa solicitó,en un tono duro, que Microsoft participase enel desarrollo de OpenDocument; aunque fueun observador del comité durante largo tiem-po, y es miembro de OASIS, Microsoft nuncaestuvo implicada activamente en el estándar.La definición no obliga a que todas las partesse impliquen, sólo a que se les dé la oportuni-dad de hacerlo.

Al igual que otras organizaciones deestándares, OASIS solicita pagos por parte delas organizaciones interesadas en desarrollar

estándares. El problema es que gente interesa-da en participar puede ser que no forme partede una organización que pueda efectuar estospagos. Sin embargo, OASIS ha trabajado duropara asegurar mecanismos que permitan aestas personas estar representadas medianteorganizaciones sin ánimo de lucro, con lo quese cumple este requisito.

Esto nos deja todavía pendiente esta mezclade requerimientos: "No favorecer a unimplementador sobre otro" y "Consenso:todos los intereses se discuten y se alcanzaun acuerdo, sin dominación". Si hubiese unvendedor que controlase realmente todas lasdecisiones, tendríamos un problema. Feliz-mente, creo que tenemos una nueva eviden-cia de que no hay dominación en el caso deOpenDocument. Si no hay dominación,OpenDocument es un estándar abierto sindiscusión. Veamos las evidencias.

3.3 Sin dominación¿Cómo podemos advertir si hay dominaciónen un grupo de estándares? Hay varias señalesque, si aparecen, ofrecen una fuerte evidencia.Por ejemplo hay dominación de un vendedor silas reglas o procesos que controlan el desarro-llo del estándar limitan fuertemente el alcancede los cambios técnicos, prohíben cambios quepodrían afectar a un solo vendedor o dan a unvendedor particular poder único de veto. Elproceso de desarrollo de OpenDocument notiene ese problema; las reglas establecidas per-miten que cualquiera proponga cambios, in-cluso aunque fuercen a uno o a todos losvendedores a cambiar sus implementaciones.Pero aun podría haber reglas no constatadasque limiten efectivamente la participación deterceros aunque no estuviesen escritas explíci-tamente.

Deberíamos comprobar si otros implemen-tadores implicados en el proceso están cum-pliendo con el mismo sin bloquearlo, aun-que eso no es siempre un indicador válido.En este caso no parece existir ese problema.Bob Sutor (IBM) señala que "IBM y Sunestán trabajando juntos feliz y efectivamenteen el formato OpenDocument. Creo quehemos progresado enormemente en el últi-mo año gracias a la amplia cooperación de lacomunidad" [12]. De hecho, Andy Updegrovedice que para la estrategia de Sun e IBM esclave "tener muchas aplicaciones que sopor-ten ODF…".

Lo que necesitamos ahora es una evidenciadirecta de que no hubo dominación en eldesarrollo de OpenDocument. Una formasencilla de comprobarlo es ver si sólo unaparte está haciendo esencialmente todos loscambios, o si en realidad otros están hacien-do propuestas que provoquen cambios téc-nicos a la especificación que afecten a losimplementadores. Particularmente signifi-cativos son los cambios que hacen que todos

novática nº 184 noviembre-diciembre 2006 17

Formato de Documento Abierto (ODF) monografía

monografía

los implementadores tengan que hacer cam-bios significativos a sus productos. Si todoslos implementadores cambian sus produc-tos para ajustarse a la especificación clara-mente no hay un implementador que pro-ponga todos los cambios.

Comencemos analizando quienes propusie-ron el documento base original y quienespropusieron cambios que se aceptaron. Eldocumento base original fue aportado porSun y el grupo OpenOffice.org, claramenteimplicados. Su documento base se basó ensu experiencia real de utilizar el formatocomo su formato primario lo que es comple-tamente perfecto... Teníamos un documentobase fundado en experiencia real.

¿Podemos pensar que Sun y OpenOffice.orglo controlaban todo, o se hicieron cambios ala especificación por terceros? Sun yOpenOffice.org contribuyeron con el docu-mento original, y con algunos cambios mástarde, pero yo consulté a miembros del comi-té técnico y ellos me demostraron con faci-lidad que muchas otras organizaciones hi-cieron cambios importantes a la especifica-ción. En algunos casos es difícil decir quienfue el proponente, pero hay evidencias másque suficientes que muestran que hubo mu-chos implicados. Incluso en los casos en quese ha identificado al proponente es obvio quelos cambios obligaron a los implementadoresa cambiar sus implementaciones.

En la tabla 3 tabla 3 tabla 3 tabla 3 tabla 3 se muestra una larga1 lista deejemplos de muchos cambios sobre el do-cumento base aportado por Sun/OpenOffice.org, hasta convertirse en OpenDocument.No necesitamos leer la información con de-talle; lo importante es que es un largo con-junto. Estoy seguro de que hay muchos otroscambios no listados en la tabla, pero creoque hay bastantes para demostrar que esresultado del trabajo de muchos, no unaespecificación controlada por un vendedor.

Se hicieron otros cambios para mejorar eldocumento como documento. Un gran cam-bio fue la sustitución del lenguaje de defini-ción de esquema por RELAX-NG, un len-guaje de especificación estándar mucho más

poderoso que DTD y más sencillo de com-prender. Otra ventaja de este añadido es quelas pruebas de validación de los ficherosOpenDocument pueden ser mucho más ri-gurosas. Esto redunda en un mejor resulta-do de interoperabilidad; RELAX-NG puedeser mucho más específico sobre los valorespermitidos en las expresiones, eliminandoposibles errores de los implementadores.

Evidentemente, hubo muchos cambios trasla remisión inicial del documento base, gra-cias a la interacción de todos los miembros.El primer borrador de la especificación ori-ginal tenía 108 páginas, y su esquema 69K.La versión final tiene cerca de 723 páginas ysu esquema 529K. Este crecimiento hacia unestándar completo se produjo mediante larevisión cuidadosa de un gran número deexpertos de diferentes campos.

Un riesgo de hacer muchos cambios a unaespecificación es que el resultado final seadifícil de implementar. El proceso deOpenDocument lo evitó porque los imple-mentadores implementaban los cambioscuando se producían, y usaban múltiplesimplementaciones de código abierto comoreferencia.

Un participante comentó que "fue evidenteque los vendedores entraron en el códigofuente o lo descargaron [OpenOffice.org] yque estudiaron la implementación y los có-digos.... Las explicaciones, el razonamientoy las técnicas fueron intercambiadas de unaforma que hubiese sido imposible si no hu-biese habido una aplicación común de refe-rencia y un código fuente al que todos pudie-ron acceder."

3.4. Otra cuestión : revisión de partici-pantesHe anotado más arriba que la medida másimportante era ver si hubo cambios realizadospor muy diferentes participantes, y creo que lohe probado concluyentemente. Para tener unaevidencia adicional, revisemos los participan-tes por sí mismo ¿Encontramos los múltiplesimplementadores, usuarios, y puntos de vistaque esperaríamos encontrar en un estándar nodominado por ninguna organización?

De nuevo, pienso que la respuesta es "sí". Lasede web de OASIS ofrece muchos detalles,la Wikipedia también. Primero, una breveintroducción. La versión 1.0 de la especifica-ción OpenDocument se desarrolló tras unalarga discusión entre múltiples organizacio-nes. La primera reunión oficial de OASISpara discutir el estándar fue el 16 de diciem-bre de 2002; la aprobación como estándar deOASIS se produjo el 1 de mayo de 2005.Hubo dos años y medio de duro trabajo; noes fácil crear una buena especificación.

El proceso de estandarización reunió a losdesarrolladores de muchos paquetesofimáticos, incluyendo (en orden alfabético):

Adobe (Framemaker, Distiller).Arbortext (Arbortext Enterprise PublishingSystem).Corel (WordPerfect).IBM (Lotus 1-2-3, Workplace).KDE (KOffice).SpeedLegal (sistema de ensamblaje de do-cumentos de la empresa Smart Precedent);ambos, el producto y la compañía cambia-ron su nombre más tarde a Exari.Sun Microsystems / OpenOffice.org(StarOffice/OpenOffice.org).

Hay muchos implementadores, algunos delos cuales son competidores directos, y re-presentan un amplio abanico de contextos.Es un buen síntoma que implementadoresen competencia trabajen juntos en el estándar.

Otra buena señal es que hubo implicadosusuarios con campos y problemas específi-cos:

Boeing (grandes documentos complejos).CSW Informatics.Drake Certivo.Intel (grandes y complejos documentos;desarrollan documentos de ejemplo comoelementos de prueba).National Archives of Australia (recuperandocumentos mucho tiempo después de sudesarrollo).New York State Office of the AttorneyGeneral (recuperan documentos muchotiempo después de su desarrollo).Novell.Society of Biblical Literature (grandes do-cumentos multilingües, recuperación a lar-go plazo).Sony.Stellent.

Mi favorito particular es la "Society of BiblicalLiterature", por lo inesperado - ¡creo quenunca la invitamos! Este grupo está preocu-pado por grandes documentos multilingües,en cualquier lengua viva o en lenguas muer-tas, y por la recuperación de información alargo plazo, incluso milenios.

Otra forma de demostrar la verdadera diver-sidad es ver los diferentes objetivos de los

Tabla 3. Extracto de los cambios realizados a la primera especificación de Open Document.

Cambio Proponente Modificación para permitir múltiples campos de metadatos. La especificación original no lo permitía (por ejemplo, sólo un autor por documento). En la primera reunión presencial se urgió este cambio, y el primer borrador de OASIS ya lo incluyó.

Patrick Durusaru (Society of Biblical Literature)

Se añade SVG para soportar gráficos de vectores utilizando un estándar ya existente y se trabaja para resolver las cuestiones relacionadas con el uso de SVG.

Paul Langille (Corel)

… Se añade el atributo fo:margin (16); mejora la manipulación de márgenes.

David Faure (KDE).

novática nº 184 noviembre-diciembre 200618

monografía Formato de Documento Abierto (ODF)

monografía

diferentes grupos. Michael Brauer, el presi-dente, insiste en que el único objetivo de sugrupo es soportar el "trabajo del paqueteofimático de escritorio". Otros, como GaryEdwards, creen que OpenDocument cubretres áreas:

Entorno de productividad de escritorio:formato de fichero de escritorio.

Arquitectura orientada a servicios (SOA):capa de transformación universal enlazandoescritorios mediante flujos SOA XML.

Open Internet: ODF como el sucesor dellenguaje HTML/XHTML.

Gary Edwards ha señalado que Boeing esta-ba realmente interesado en SOA, por ejem-plo. No hay necesidad de declarar qué con-junto de objetivos es "correcto". Organiza-ciones diferentes se unieron al grupo porquetenían objetivos diferentes, sin sorpresas, yal final todas creyeron que sus (diferentes)objetivos se habían alcanzado. Son muybuenas noticias. Un estándar que puede cum-plir los diferentes objetivos de diversas orga-nizaciones tiende a ser un buen estándar entanto sea implementable... y dado que ODFha sido implementado, no hay dudas.

En realidad, el hecho de que Boeing quisieraque la especificación fuese tan buena quepudiese ser una "capa de transformaciónuniversal" es una excelente evidencia de lascapacidades de OpenDocument. Para cum-plir este rol, OpenDocument tiene que sertan expresivo que sea capaz de capturarinformación de muchos formatos diferentesde fichero, no sólo Microsoft Office o cual-quier otro formato simple. El resultado es unestándar más general y flexible.

Aunque no es parte de la definición de un"estándar abierto", no puedo dejar de estarimpresionado por la experiencia de muchosde los participantes. Tom Magliery (Corel/XMetal) estaba en el grupo original de tra-bajo del W3C XML 1.0 (y en el grupo origi-nal del navegador NCSA Mosaic). PhilBoutros (Stellent) es un experto en formatosde fichero de Microsoft. Paul Grosso (fun-dador de ArborText) fue presidente del pro-yecto XSL:FO. Doug Albert (Boeing) com-prendía muy bien las necesidades de publi-cación de las empresas y de los sistemas degestión de contenidos. Patrick Durusau esun reputado experto en SGML, etc.

Esto demuestra que es una buena idea crearestándares a través de un proceso abierto –reuniendo a los expertos, de forma que se lesdeje solucionar los problemas que encuen-tran, un grupo de expertos puede alcanzarun muy buen resultado.

4. ConclusionesSin duda, OpenDocument es un estándarabierto. Cumple cada requerimiento de unarigurosa (combinada) definición de "estándar

Referencias

[1] Andy Updegrove. OpenDocument Approved byISO/IEC Members. <http://www.consortiuminfo.org/standardsblog/article.php?story=20060503080915835>.[2] Wikipedia. OpenDocument <http://en.wikipedia.org/wiki/OpenDocument>.[3] Wikipedia. OpenDocument adoption <http://en.wikipedia.org/wiki/OpenDocument_adoption>.[4] VALORIS. Comparative Assessment of OpenDocuments Formats. Market Overview. <http://europa.eu.int/idabc/servlets/Doc?id=17982>.[5] David A. Wheeler. Answering Microsoft:Comments on Microsoft’s Letter to MA. <http://www.groklaw.net/article.php?story=20051029212458555>.[6] Bruce Perens. Open Standards: Principles andPractice. <http://perens.com/OpenStandards/Definition.html>.[7] Ken Krechmer. The Meaning of Open Standards.<http://www.csrstds.com/openstds.html>.[8] Rick Jelliffe. A little freaked out by ODF’s definitionof Open Standard. <http://www.oreillynet.com/xml/b l o g / 2 0 0 6 / 0 9 / f r e a k e d _ o u t _ b y _ o d f s _definition.html>.[9] Comisión Europea. The ‘European InteroperabilityFramework for pan-European eGovernment Services’.<http://europa.eu.int/idabc/en/document/3761>.[10] Rishab Aiyer Ghosh. EC announces OpenStandards Definition. <http://trends.newsforge.com/article.pl?sid=04/11/19/148236>.[11] OASIS. <http://www.oasis-open.org/committees/office/>.[12] Andy Updegrove’s blog. <http://www.consortiuminfo.org/standardsblog/article.php?story=20060313130200943>.[13] IDABC Programme. TAC approval on conclusionsand recommendations on open document formats.<http://europa.eu.int/idabc/en/document/2592/5588>.

1 Nota del Editor: En el artículo original <http://www.groklaw.net/article.php? story=20060209093903413> el autor incluye la descripción de hasta25 cambios distintos promovidos por proponentesmuy diversos. Por razones de espacio, hemos tenidoque abreviar y publicamos solamente 3 de los 5primeros de la lista de Wheeler.

Nota

abierto", con muchísimas evidencias. En par-ticular, existe la evidencia significativa deque no estuvo controlado por ningún vende-dor.

Y esto es bueno. Cuando envío un documen-to sólo de texto, nadie pregunta ¿lo creastecon WordPad, con vim o con emacs? Cuan-do envío un mapa de bits en PNG, nadiepregunta si lo creé con GIMP o conPaintShop Pro. ¿Por qué? Porque no impor-ta. Los formatos de datos que son estándaresabiertos pueden ser implementados y com-prendidos por todos. Usándolos, soy librepara utilizar la herramienta que quiera.

Los gobiernos se están empezando a darcuenta de lo importantes que son losestándares abiertos:

Erkki Liikanen, comisionado de la UniónEuropea, dijo "Los estándares abiertos sonimportantes para ayudar a crear solucionesasequibles e interoperables para todos. Pro-mueven la competencia definiendo un cam-po técnico de juego que establece el nivelpara todos los jugadores. Esto supone me-nos costes para las empresas y, finalmente,para el consumidor".

El Comité Europeo de Telemática entreAdministraciones (TAC) dijo: "A causa desu papel específico en la sociedad, el sectorpúblico debe evitar que un producto especí-fico fuerce a cualquiera a interactuar con élelectrónicamente. En cambio, debe ser po-tenciado cualquier formato de documentoque no discrimine contra actores del merca-do y que pueda ser implementado entre pla-taformas. El sector público debería evitarcualquier formato que no salvaguarde laigualdad de oportunidades de los actores delmercado para implementar aplicaciones deprocesamiento de formatos, especialmentedonde esto pueda imponer una selección deproducto a los consumidores o a los nego-cios. En este sentido, las iniciativas deestandarización asegurarán no sólo un mer-cado limpio y competitivo, sino que salva-guardarán la interoperabilidad de las solu-ciones que se implementen, mientras preser-van la competencia y la innovación".

En resumen, los estándares abiertos creanlibertad frente al control de otros. Es unalibertad que todos deberíamos experimen-tar.

AgradecimientosDebo dar las gracias a toda la gente que me ayudóa encontrar información para este trabajo, inclu-yendo a Daniel Carrera, Patrick Durusau, GaryEdwards, J. David Eisenberg, David Faure y Da-niel Vogelheim.

novática nº 184 noviembre-diciembre 2006 19

Formato de Documento Abierto (ODF) monografía

monografía

1. Las verdaderas ventajas deOpenDocumentUn formato de fichero XML (eXtensibleMarkup Language) altamente estructura-do, rico en metadatos e independiente deaplicaciones, como OpenDocument, puedefinalmente ofrecer dos enormes ventajas atodos los usuarios de computadores y a lasociedad vista como un todo. La primera esla interoperabilidad completa entre muchasaplicaciones software, independientementede su interfaz de usuario, licencia o modelode desarrollo. Merece la pena mencionarque esta capacidad no se limita al softwarede productividad ofimática, sino que seráutilizable o útil en un rango de productosmucho más amplio. Tratándose de XML,los ficheros pueden generarse al vuelo, o seranalizados o indizados automáticamente porcualquier tipo de aplicaciones, independien-tes del servidor.

La otra cuestión realmente importante esque OpenDocument hace posible, a granescala y por primera vez, el archivo a largoplazo, sin pérdida de información, de docu-mentos digitales ofimáticos. Esto no es posi-ble con otros estándares, incluso con aque-llos especialmente desarrollados para archi-vo, como PDF/A (Portable DocumentFormat Archive). Este último "sólo se dirigea aquellos ficheros que pueden describirsecomo una representación digital de un docu-mento en papel" y "asegura que un documen-to PDF se mostrará tal como fue creadopasados 50 años" [1]. En consecuencia, PDF/A es adecuado sólo cuando la única versiónabierta disponible de un documento es unfichero PDF, o para documentos creadosmediante escaneo de originales en papel.Los documentos PDF/A, por ejemplo, noson capaces de conservar la historia y, sobretodo, los algoritmos internos del documentooriginal. No conservan versiones diferenteso las fórmulas que generan los números yresultados en una hoja de cálculo. Esta limi-tación haría que el futuro análisis histórico ocientífico de documentos tales como pro-puestas de ley, informes de elecciones oestudios sobre calentamiento global, fueramucho más difícil de lo que sería si losdocumentos hubieran sido almacenados enformato OpenDocument.

Desde luego, el archivo confiable a largoplazo depende de más variables que de úni-camente el formato, y estas variables pue-

den ir desde el medio físico a las especifica-ciones del sistema de ficheros, pero estascuestiones quedan fuera del objetivo de estetexto.

2. Impacto de OpenDocument enla comunidad FOSSMuchos defensores de FOSS, incluyendopolíticos que piensan que FOSS creará pues-tos de trabajo locales en el área de las tecno-logías de la información, todavía no se handado cuenta de que la adopción deOpenDocument podría retrasar la adopciónde FOSS en varios escenarios o, en algúncaso, cambiar la forma en que se desarrollany soportan las aplicaciones FOSS de escrito-rio.

Casi todas las grandes organizaciones pú-blicas y privadas poseen una infraestructurade tecnologías de la información grande yparcialmente pagada, que llevaría años mi-

grar. El único factor que realmente dificultala interoperabilidad dentro de estas organi-zaciones, o entre ellas, no es el software queejecutan: es el hecho de que solo puedenproducir o aceptar formatos propietarios defichero, para los cuales, por definición, losfiltros FOSS nunca pueden ser perfectos.

Además, en muchos países la intero-perabilidad y la propiedad de los datos pue-den ser realmente incluidas como requeri-mientos obligatorios en ofertas y propuestaspúblicas. Es inmensamente más sencillo ymucho más coherente, al menos en unasociedad libre, trabajar para conseguir unasleyes que sólo requieran formatos y protoco-los libres, y no cualquier producto softwareespecífico, cualquiera que sea su licencia.

Imponer la adopción de OpenDocument esla línea de acción más sencilla y más efectivaen este contexto. Sin embargo, para leer o

Trampas ocultas en OpenDocumenty efectos secundarios en el software

libre y de código abierto

Marco FiorettiOpenDocument Fellowship

<marco.fioretti@opendocumentfellowship.org><marco.fioretti@opendocumentfellowship.org><marco.fioretti@opendocumentfellowship.org><marco.fioretti@opendocumentfellowship.org><marco.fioretti@opendocumentfellowship.org>

Traducción: Traducción: Traducción: Traducción: Traducción: Jesús Tramullas Saz (Universidad de Zaragoza).

Resumen: OpenDocument es ampliamente considerado, en especial dentro de la comunidad Free/Open Source Software (FOSS), una de las herramientas más importantes para la promoción de lapropia FOSS y de un mercado de tecnologías de la información (TI) verdaderamente libre. OpenDocumenttambién es considerado esencial, en lo que a las TI concierne, para la construcción de una sociedad yde una cultura ambas más libres. La naturaleza de OpenDocument, sin embargo, no es suficiente parasuperar algunos obstáculos en la consecución de estos objetivos y, en cualquier caso, es muy proba-ble que tenga un profundo, y a veces inesperado, efecto en el propio futuro de la FOSS. Este artículopresenta esos obstáculos y efectos secundarios y, cuando suponen problemas reales, describe breve-mente la mejor solución para hacerles frente.

Palabras clave: administraciones públicas, archivo a largo plazo, certificación, código abierto, estándaresabiertos, OpenDocument, propiedad de datos, software libre.

Autor

Marco Fioretti es ingeniero de sistemas hardware y escritor independiente para varias revistas sobreLinux y Tecnologías de la Información. Es cofundador (2002) y actual coordinador del Run Up to dateLinux Everywhere Project <http://www.rule-project.org/>, que hace el moderno software libre fácil-mente instalable en ordenadores más antiguos. Siempre ha estado interesado en los verdaderos formatosde fichero y protocolos abiertos, desde e-books hasta bases de datos portátiles, en el UBL (UniversalBusiness Language), y en sus impactos en la economía, la educación y los derechos civiles. En el 2004investigó las relaciones filosóficas entre el software libre y el escultismo (movimiento scout). Con esemismo espíritu, cofundó, en el 2006, Eleutheros (una aproximación católica a la informática, <http://www.eleutheros.it/>), que promueve una adopción amplia y oficial del software y formatos no propie-tarios dentro de la Iglesia católica. Más recientemente, Fioretti ha comenzado a seguir los esfuerzos delas comunidades de software libre y de discapacitados para comunicarse de una manera más efectiva.Su iniciativa más reciente para promocionar la importancia del software y de los estándares abiertosentre todos los ciudadanos es Family Guide to Digital Freedom <http://digifreedom.net>. Marco Fioretties miembro, y a la vez la persona de contacto en Italia, de la OpenDocument Fellowship <http://opendocumentfellowship.org/>, una organización de voluntarios que promueve el uso y desarrollo delformato OpenDocument, y el autor de la Everybody’s Guide to OpenDocument <http://www.linuxjournal.com/article/8616>.

novática nº 184 noviembre-diciembre 200620

monografía Formato de Documento Abierto (ODF)

monografía

producir ficheros OpenDocument, un usua-rio de Micrososft Office no tiene necesidadde migrar a OpenOffice o a Linux. Todo loque necesita es instalar, o tener instalado, unplugin para Microsoft Office como el queestá siendo desarrollado por laOpenDocument Foundation [7]. En otraspalabras, sólo con añadir soporteOpenDocument a la infraestructura existen-te, la mayoría de los usuarios públicos yprivados pueden tener muchas menos razo-nes o presiones para migrar a FOSS. Unavez que la propiedad de datos y lainteroperabilidad están garantizadas, la mi-gración no sólo se vuelve más sencilla sinotambién menos urgente y atractiva. Enton-ces, FOSS deberá competir en otros campospara ser adoptado por los usuarios finales,sin tener en cuenta los precios de las licen-cias. Las prestaciones sobre un hardwarelimitado, la usabilidad, la documentaciónde usuario final, o el soporte en línea gratui-to para no programadores deberán serconsistentemente mejores que las del soft-ware propietario para convencer a los usua-rios de migrar y utilizar soluciones FOSS.

Algunos defensores de FOSS probablemen-te se preocuparán por estas nuevas tenden-cias, pero sería equivocado luchar contraellas. En primer lugar, porque la adopciónobligatoria de OpenDocument haría que in-mediatamente el 100% de los escritoriosFOSS de estudiantes y de pequeñas empre-sas fueran compatibles con los sistemas pro-pietarios existentes en gobiernos y corpora-ciones. A través de OpenDocument, los es-critorios FOSS se volverían mucho másusables para los negocios, la investigación yla política activa de lo que lo son hoy y hansido antes. En segundo lugar, porqueOpenDocument mejorará la calidad deFOSS, precisamente por las razones quehemos mencionado.

3. Trampas ocultasEs muy probable que, al final, los mayoresproveedores de software libre y propietariodel ámbito de los ficheros ofimáticos sopor-ten OpenDocument. Sin embargo, el estándaren sí mismo permanece abierto de variasformas a seguir manteniendo los monopo-lios como posibles o a invalidar su utilidadpara el archivo a largo plazo.

Técnicamente hablando, OpenDocument esmuy poderoso y útil porque puede extender-se. Robert Weir, ingeniero de software enIBM Software Group, discutió recientemen-te con el consorcio de estándares médicosMedBiquitous <http://www.medbiq.org/>un formato para certificados médicos basa-do en OpenDocument, que añadiría a cadadocumento metadatos XML firmadosdigitalmente. Sin embargo, la extensibilidades neutral con respecto a las intenciones. Esposible tener un contenedor XML perfecta-

mente libre, lleno de componentes protegi-dos por patente. El hecho de que un estándarde fichero ofimático no sea propiedad ni estécontrolado por un vendedor puede hacermás sencillo, no más difícil, que aparezcanextensiones propietarias para mantener a losusuarios cautivos, al menos en algunos esce-narios. A continuación, revisaremos breve-mente las principales formas en que estopuede ocurrir, y discutiremos la soluciónmás adecuada para evitarlo.

3.1. Cuestiones generalesCada lugar en la especificaciónOpenDocument en la que puede introducirseun espacio de nombres para elementos defi-nidos externamente es un punto de entradapara extensiones propietarias, si no se publi-can los espacios de nombres, y si los esque-mas y semántica de los elementos no sepublican integramente para su utilizaciónlegal. Por ejemplo, está permitida la intro-ducción arbitraria de etiquetas extrañas pordebajo del nivel de párrafo así comometadatos arbitrarios de documento (sec-ción 2.2), propiedades de formateo (sección15) y sus características predeterminadaspor la aplicación. El estándar también espe-cifica cómo deberían tratarse las etiquetasdesconocidas y, sobre todo, establece quealgunas de ellas deberían ser preservadas.

Como ejemplo práctico, OpenDocumentpreserva objetos OLE (Object Linking andEmbedding) y visualizaciones alternativaspara imágenes, para mantener la compatibi-lidad si el documento es reexportado a Office.Todos estos elementos "extraños", sin em-bargo, son intrínsecamente inseguros parasu uso en intercambio, ya que no hay untratamiento predecible para ellos más allá deuna preservación opcional y pasiva. Un aná-lisis más detallado, aunque no completo, dela especificación actualizada se encuentra enla referencia [6].

3.2. Formatos multimediaLa especificación OpenDocument contem-pla, obviamente, la inclusión de imágenes,audio o cualquier otro objeto multimedia entextos, hojas de cálculo y presentaciones. Sinembargo, no dice nada sobre la licencia ocualquier restricción de propiedad intelec-tual de los formatos de fichero correspon-dientes, por lo que es perfectamente legal (enlo concerniente al estándar) incluir conteni-do multimedia en formatos propietarios orestringidos por patentes dentro de docu-mentos OpenDocument.

3.3. MacrosLas macros son la única vía real, para usua-rios no programadores de paquetesofimáticos, de alcanzar dos objetivos intrín-secamente diferentes: uno es extender lafuncionalidad de un software específico entodos los ficheros sobre los que opera:

interfaces de diccionario, revisores ortográ-ficos, contadores de palabras y otros simila-res entran dentro de esta categoría. El otro esembeber algún tipo de capacidad de procesode datos o interactividad en un documentoespecífico: un ejemplo del mundo real puedeser un curso de e-learning, utilizable inclusosin conexión a Internet, hecho con formula-rios interactivos. Esto es similar a lo queocurre con los navegadores web. Hay exten-siones de Firefox y páginas web con appletsde JavaScript que pueden ejecutarse en cual-quier navegador.

Las macros del primer tipo no tienen nadaque ver con OpenDocument, pero el escena-rio del curso interactivo es diferente. Si esecurso consiste en formularios dentro de do-cumentos de texto u hojas de cálculoOpenDocument, los usuarios y distribuido-res esperarán que todos los botones, camposde formulario, casillas de verificación y en-tradas para usuarios funcionen sin proble-mas dentro de cualquier programa confor-me a OpenDocument, tanto ahora como enla próxima década. El estándar, sin embar-go, especifica cómo las macros deben embe-berse en el documento, pero no cuál deberíaser su lenguaje.

3.4. Bases de datos en ficheroLas bases de datos sin servidor SQL(Structured Query Lenguage), en ficherossimples, que además de los datos contienenesquemas, índices y estructuras de formula-rios no son tan poderosas como las solucio-nes SGBDR (Sistema General de Bases deDatos Relacionales), pero son extremada-mente útiles en un caso muy común e impor-tante. Hacen posible para todos los usua-rios, incluso aquellos sin conocimientos deprogramación, clave de administrador nipermiso para instalar software en sus orde-nadores, crear bases de datos tan fácilmentecomo texto o imágenes [3]. La popularidadde MS Access en las oficinas pequeñas es unbuen ejemplo de ello.

Los ficheros OpenDocument pueden incluireste tipo de bases de datos. OpenOffice, porejemplo, usa HSQLDB (HyperthreadedStructured Query Language Database) comoformato predeterminado para este caso. Engeneral, los ficheros OpenDocument pue-den ser enlazados dinámicamente con basesde datos externas. En ambos casos, se apli-can las mismas cuestiones que para objetosmultimedia: nada en el estándar impide quelas bases de datos enlazadas o embebidassean propietarias o no estén documentadas.

3.5. Firmas digitales y otras extensio-nes de seguridad relacionadasLos gobiernos y las grandes corporacionesestán interesados en dar o negar acceso adiferentes partes de un mismo documento.Un informe interno, por ejemplo, puede

novática nº 184 noviembre-diciembre 2006 21

Formato de Documento Abierto (ODF) monografía

monografía

publicarse en Internet con tan sólo cifraralgunos párrafos. Un fichero OpenDocumentpuede incluso contener su propia firmadigital, para certificar su autenticidad. In-cluso pueden firmarse metadatos individua-les, como en el caso de MedBiquitous. Denuevo, cualquier algoritmo criptográfico, conindependencia de su licencia o de lo comple-ta que esté su documentación pública, puedeusarse para este propósito.

3.6. FórmulasLa versión 1.0 de OpenDocument no estableceun formato común para las fórmulas incluidasen las hojas de cálculo, lo que crea conocidosproblemas de interoperabilidad [4]. Esta cues-tión, sin embargo, será resuelta en la versión1.2 del estándar, por lo que sólo afecta aficheros OpenDocument archivados ya, o quelo sean en los próximos 12 meses.

3.7. Tipos de letraLos tipos de letra son referenciados por sunombre, por ejemplo Times New Roman.Desde luego, se usan sólo para presentación,no para codificación de información. Estono creará problemas sustanciales deinteroperabilidad ni de conservación, perousar tipos propietarios, o sólo disponibles endeterminadas plataformas puede crear pro-blemas innecesarios, por ejemplo haciendoimposible la distribución de copias impresassin modificaciones. Esto es especialmenteimportante para documentos científicos otécnicos con muchas fórmulas complejas.

4. Naturaleza de la soluciónComo hemos visto, el cumplimiento al 100%de la norma ISO26300 no es suficiente paragarantizar que un informe o una propuesta deley almacenada hoy sean legibles y utilizablesdentro de 20 años. Para que esto sea posible,todos los componentes de estos ficheros debe-rían ser tan abiertos y documentados como loes el propio OpenDocument, pero es posible yrelativamente fácil que ocurra al revés, mante-niendo a los usuarios bloqueados en un soft-ware propietario o específico. Los beneficiosde OpenDocument, es decir, la completainteroperabilidad y el archivo a largo plazo sinpérdida de información se pierden en amboscasos.

Como consideración general, sólo una partede la solución es técnica y puede hacerse enlas aplicaciones. Por ejemplo, una buenaopción sería tener en OpenOffice (o en cual-quier procesador de textos) una conversiónautomática de gráficos a un formato abierto,como PNG (Portable Network Graphics) oSVG (Scalable Vector Graphics). Lo mismopodría hacerse con los tipos de letra. Cuan-do se trate de bases de datos, los procesos dearchivo deberían hacer, cuando sea necesa-rio, una inclusión automática de la base dedatos enlazada desde el ficheroOpenDocument.

Los revisores automáticos de XML que ex-ploren los documentos OpenDocument ymarquen cualquier componente cerrado,comparando su formato contra una lista deaceptados, serían muy fáciles de hacer y muyútiles. Las administraciones públicas y lasbibliotecas podrían actuar igual que unantivirus, rechazando cualquier documentocuya interoperabilidad no esté aseguradaahora ni en el futuro.

A otro nivel, pero también técnico, las prue-bas de interoperabilidad bien definidas sonesenciales para diferenciar las implemen-taciones realizadas con intención de coope-rar. La Universidad Central de Florida, porejemplo, está trabajando en un paquete depruebas para OpenDocument que permiti-ría verificar la conformidad de software pre-parado para OpenDocument con la especi-ficación [5].

En el fondo sin embargo no se trata de unacuestión de la especificación de formatos. Laespecificación de OpenDocument o su licen-cia no debería y no podría contener, permitiro prohibir nada, ninguna extensión concebi-ble, por no mencionar aquellas que todavíano existen. Esto está implícito en el verdade-ro concepto de un estándar abierto y exten-sible: debe facilitar el intercambio de datosentre implementaciones que deseen ese in-tercambio, pero no puede forzar la compa-tibilidad cuando ésta no se produzca. Elproblema debe resolverse de otra forma, quesólo es técnica en parte.

El primer paso es aumentar el conocimiento,entre administradores de sistemas y responsa-bles de políticas, de que estos problemas exis-ten y de que deben ser afrontados antes de quese conviertan en un problema serio. El segundoes implementar los revisores automáticos men-cionados anteriormente. El tercer paso po-dría ser definir oficialmente un OpenFile omarca similar que sea aplicable sólo a fiche-ros en los cuales no hay ningún componentecon licencias restrictivas o documentaciónincompleta. Parte del problema es definirquién debería llevarlo a cabo. En la Comuni-dad Europea un buen candidato sería la orga-nización Interoperable Delivery of Pan-European eGovernment Services to publicAdministrations Business and Citizens(IDABC, <http://europa.eu.int/idabc/>).

El último y más importante paso sería en esemomento requerir, por ley, que todos losficheros OpenDocument almacenados ointercambiados con administraciones públi-cas, bibliotecas y otras entidades fueranOpenFile, independientemente de la aplica-ción que las haya creado.

Hay varios casos claros en los que puede serinevitable ofrecer excepciones a la regla, almenos a corto y medio plazo.

Hacer que los documentos públicos sean ypermanezcan completamente abiertos semantiene, desde luego, como un prerrequisitoobligatorio para una verdadera sociedadabierta, y OpenDocument, en solitario, no essuficiente para alcanzar este objetivo.

Referencias

[1] Martin Bailey. Why Would Anyone Write a PDFStandard Just for Archivists?, <http://www.pdfzone.com/article2/0,1895,1841569,00.asp>,29 de julio de 2005.[2] Marco Fioretti. Macros an obstacle to officesuite compatibility, <http://software.newsforge.com/article.pl?sid=05/09/09/1640253>. 17 deseptiembre de 2005.[3] Marco Fioretti. The Lack of a Small UnifiedDatabase, <www.linuxjournal.com/article/7800>.28 de septiembre de 2004.[4] Marco Fioretti. OpenDocument office suiteslack formula compatibility. <http://software.newsforge.com/software/05/09/09/192250.shtml?tid=93>. 20 de septiembre de 2005.[5] Open Document Fellowship. Open DocumentSample Documents. <http://testsuite.opendocumentfellowship.org/>.[6] Dennis E. Hamilton Unofficial analysis of theOpenDocument specification <http://orcmid.com/writings/2005/06/w050601b.htm>. 11 de octu-bre de 2006.[7] The OpenDocument Foundation, Inc.<www.opendocumentfoundation.us>.

novática nº 184 noviembre-diciembre 200622

monografía Formato de Documento Abierto (ODF)

monografía

1. Contextualización histórica1. Contextualización histórica1. Contextualización histórica1. Contextualización histórica1. Contextualización histórica

1.1. La edad media de la documenta-ción electrónicaDesde el momento en que se dejaron de usarlos "vi", "emacs" y "edit" para redactar docu-mentos en formato ASCII, sin másmaquetación que la que rudimentaria y ar-tísticamente se le pudiera dar añadiendo oeliminando espacios y algunos caracteresespeciales usados decorativamente, laofimática ha estado dominada por formatosde documentos que en general han cumplidolas siguientes cuatro características:1) El formato era dependiente de la aplica-ción que lo generaba y por tanto de la empre-sa dueña de la misma.2) El formato era secreto y exclusivo de cadadeterminado fabricante y, a lo más, otroscompetidores o desarrolladores llegaban asoportarlo usando costosas técnicas de in-geniería inversa o pagando cuantiosas su-mas previa firma de contratos de nodesvelación de secreto alguno sobre mismo.3) Toda la población quedaba en la prácticaobligada, "para ser compatible", a utilizar elformato (y la aplicación) del operador domi-nante en el mercado en ese momento.4) Generalmente esas aplicaciones han es-tado sujetas a licencias no libres, siendo sucódigo tan cerrado como el propio formato.

Así, desde los años ochenta, y salvando ca-sos excepcionales como LaTeX, el técnicoDocBook y los formatos de OpenOffice yamucho más tarde, todos los usuarios y com-pradores de aplicaciones ofimáticas han es-tado obligados factualmente a disponer siem-pre de aquella aplicación que en cada mo-mento acabó imponiéndose en el mercadopara de esa forma ser capaces de intercam-biar documentos con el resto de la sociedad.Esto ocurrió con aplicaciones comoWordStar en primer lugar, despuésWordPerfect, tras ello y con menor intensi-dad AmiPro, y por último con las que acaba-ron dominando gracias al práctico monopo-lio de su fabricante en los sistemas operativosde las computadoras personales: MS-Office.

La característica común de todos estosformatos ha resultado en que si alguien teenviaba en cualquier momento un documen-to en un formato y/o versión distinto a laaplicación que tú utilizabas, por fuerza esta-bas obligado a "buscarte la vida" y adquirir laaplicación correspondiente a dicho formatopara así poder tener acceso a la informaciónen él contenida.

En el mercado residencial la realidad es queeste acceso a la nueva aplicación segura-mente no supusiera un grave problema por-que, en la práctica social, siempre se podíarecurrir al conocido individuo acaparadorde software ilegal que la proveía de formamuy barata o incluso totalmente gratuita.Sin embargo, en el mercado institucional yempresarial, aceptar un nuevo formato do-cumental siempre ha supuesto un paso bas-tante importante, que implicaba una migra-ción masiva de aplicaciones en todos lospuestos de trabajo, además del consiguientedesembolso de unos nada baladíes costes delicencia, formación e incluso adaptación dedocumentos y aplicaciones ya existentes.

Como curiosidad, en este punto siempre meviene a la memoria la notaría con la que suelotrabajar (la que me toca), y que "aún" utilizaWordPerfect en modo no gráfico. Probable-mente no necesiten intercambiar mucha docu-mentación con el exterior (de hecho soy cons-ciente de que no usan correo electrónico). Peroestas son formas de siglos pasados e impropiasde nuestra era postindustrial.

1.2. La revolución informacional:Internet y las nuevas oportunidadesEl modelo oscurantista de atar la aplicaciónal formato se sustentó, sin alternativa realalguna, hasta el momento en que la pobla-ción empezó a acceder masivamente aInternet y se comenzaron a popularizarformatos que eran independientes de aplica-ción y cuyo uso en muchos casos no estabansujeto a regalía alguna.

La razón de esta popularización fue que susoriginales creadores comprobaron que seríaimposible competir con la aplicación domi-nante (ya práctico monopolio por esos mo-mentos) si no adoptaban la táctica de romperla ligazón entre el formato y la aplicación,liberando las especificaciones del mismo, demanera que otras aplicaciones también pudie-ran usarlo y así ganar mayor economía deescala. El caso más paradigmático sería el deSun en el 1999, cuando contaba con más de40.000 empleados y sus correspondientes pues-tos de trabajo. A la hora de adquirir una apli-cación ofimática Sun se encontraba con ladisyuntiva de pagar 40.000 licencias a Microsoft

ISO-26300 (OpenDocument) vs.MS-Office Open XML

Opentia, S.L., 2007. Esta presentación se distribuye bajo la licencia "Creative CommonsAttribution-ShareAlike-NoDerivs-NoComercial 2.5 Spain License" de Creative Commons,disponible en <http://creativecommons.org/licenses/by-nc-nd/2.5/deed.es_CL>.

Alberto Barrionuevo GarcíaConsultor de gestión documental, Coordi-nador de EstándaresAbiertos.org, Vicepre-sidente de la FFII.org

<abarrio@ffii.org><abarrio@ffii.org><abarrio@ffii.org><abarrio@ffii.org><abarrio@ffii.org>

Resumen: hasta fechas recientes la Humanidad ha estado utilizando formatos documentales electrónicosque eran exclusivos y ataban a un determinado proveedor informático así como a su aplicación softwarecorrespondiente. Estos proveedores han ido cambiando a lo largo de los años a excepción del último decenio.Estos cambios han tenido como resultado millones de documentos inutilizables e inaccesibles debido aformatos obsoletos no legibles correctamente por las nuevas aplicaciones. A día de hoy y desde hace más deuna década la posición de operador dominante la ostenta la aplicación MS-Office que ata a un sistema opera-tivo del mismo fabricante, excluyendo a la mayoría del resto de operadores. Sin embargo, el advenimiento delestándar abierto ISO 26300, OpenDocument, tiene todo el potencial de cambiar significativamente este pano-rama e independizar los formatos de las aplicaciones y, a su vez, a los usuarios de su cautivismo a determina-das aplicaciones y sistemas. Contra este amplio movimiento del mercado la empresa hasta ahora dominanteen el mercado ofimático propone un formato alternativo semiabierto. Gran parte del futuro de la informática yde la forma en que se desarrollen los próximos pasos de la Era Informacional radicará en cuál formato seimponga en esta interesante batalla inaudita hasta ahora para la historia de la informática. En este artículo secomparan ambos formatos desde muchas perspectivas y se llega a una principal conclusión: sólo debequedar uno.

Palabras clave: documento electrónico, ECMA, ECMA-Office Open XML, estándar, estándares abiertos, for-mato ofimático, ISO/IEC, MS-Office Open XML, ODF, OpenDocument, software libre.

Autor

Alberto Barrionuevo García es Licenciado en Informática por la Universidad de Deusto. Es Socio Director deOPENTIA, S.L. especializada en la consultoría de estandarizaciones informáticas, en la gestión y archivo docu-mental, y en soluciones abiertas en general, así como en migraciones avanzadas a software libre a través de sufilial VIRTUA, S.L. Vicepresidente de la asociación europea Federation for Free Information Infrastructures (FFII)con sede en Munich y coordinador del Grupo de Trabajo “Open Standards” de la misma. Es además coordina-dor del grupo de trabajo y de la web EstándaresAbiertos.org. Miembro de la OpenDocument Fellowship ymiembro corporativo de la ODF Alliance. Miembro de Hispalinux. “Linux Registered User #130136”. Fuedirector de operaciones y de consultoría de OpenText Corporation para Iberoamérica. Director general, directorde operaciones y director de consultoría de IXOS Software AG para Iberoamérica y consultor técnico en SAPEspaña y Portugal.

novática nº 184 noviembre-diciembre 2006 23

Formato de Documento Abierto (ODF) monografía

monografía

necesitando además duplicar el hardware paratodos sus muchos empleados que necesitaranseguir usando Unix, o, por contra, hacer comohizo: comprar el código de una aplicaciónofimática que había en el mercado alemán,StarDivision, lo que además les proveía de unaalternativa comercializable frente al productodominante en el mercado de Microsoft.

Pero se les presentaba el problema de quemantener y actualizar una aplicación comoStarOffice es costoso y requiere un grandepartamento dedicado a ello si se quiereestar a la altura de aplicaciones competido-ras que sí lo tienen.

Y como solución a ese problema llegó elsegundo hito importante de la corta historiade los formatos electrónicos documentales.Se producía paralelo a la maduración, a finalde los 90, de un nuevo modelo de desarrolloy distribución de software de escritorio: elsoftware libre. Hasta bien poco antes, elsoftware libre había centrado sus esfuerzosen aplicaciones muy tecnificadas principal-mente orientadas a servidores y a losdesarrolladores. Pero había llegado el mo-mento de su salto al mundo del escritorio.

Así, Sun, un año después de la compra, en unadecisión eminentemente financiera y comer-cial, libera no sólo las especificaciones delformato de StarOffice, sino incluso el códigode las mismas para crear un proyecto de soft-ware libre paralelo que mantuviera, usara ydifundiera sus formatos. Era el lanzamientodel proyecto OpenOffice.org. El mismo desdeel que se están escribiendo estas líneas.

La realidad es que ésa era la única vía renta-ble, para una empresa de hardware comoSun, de competir contra una aplicación prác-ticamente monopolística que tenía a todoslos usuarios muy cautivos: la de Microsoft.En paralelo, Sun decidía seguir comerciali-zando su versión cerrada de StarOffice ba-sada en el código libre de OpenOffice.org ya la que añadía cierta funcionalidad adicio-nal. Este modelo de doble licencia y produc-to ya había sido utilizado por otra de lasaplicaciones barridas del mercado por elmonopolio de sistemas operativos deMicrosoft: el olvidado Netscape, germen cualave fénix del actual y exitoso Mozilla-Firefox.

En conclusión, tras todo esto por fin seconseguía disponer comercialmente de unosformatos documentales abiertos que cubríantodas las funcionalidades de la aplicacióndominante y que además podían ser aprove-chados por otros muchas otras aplicacionesofimáticas alternativas que ya existían en elmercado..., como así ocurrió.

2. Estándares documentales2. Estándares documentales2. Estándares documentales2. Estándares documentales2. Estándares documentales

2.1. ¿Y por qué no un estándar abier-to?: OpenDocumentTras unos años padeciendo de algunos so-

nados estándares informáticos demasiadoteóricos, complejos y fallidos a la hora dellevarlos a la práctica, las organizacionesoficiales de normalización internacionalesdecidieron crear estándares basados en pro-tocolos o formatos provenientes del merca-do, que además ya hubieran probado suvalía en el mundo real. A ello probablementeayudó el que muchas empresas se reunierancreando sus propias organizaciones no gu-bernamentales alternativas con las que desa-rrollar estándares industriales. Este fue elcaso, por ejemplo, de la organización OA-SIS (Organization for the Advancement ofStructured Information Standards), forma-da por casi todos los grandes desarrolladoresde software a nivel mundial.

Y éste ha sido el caso del formato documen-tal independiente, abierto y orientado a serusado por todos, creado y mantenido porOASIS, y que toma como base de trabajo losantiguos formatos de StarOffice yOpenOffice.org: el formato OpenDocument.

La propia OASIS describe que la misión delComité OpenDocument1 desde sus orígenesa finales del 2002, era "crear una especifica-ción de formato de fichero abierto y basadoen XML para aplicaciones ofimáticas". Estoes, el formato debería ser genérico y estarorientado a todas las aplicaciones ofimá-ticas..., que, claro, voluntariamente decidie-ran utilizarlo. Seguidamente comprobare-mos que a día de hoy han sido prácticamentetodas, excepto una.

Pero en todo caso, lo importante, y diferenciadorcomo veremos, es que el estándar no se creó aimagen y semejanza del formato e intereses deuna aplicación o fabricante alguno, sino quefue corregido y remodelado de forma total-mente abierta a todas las partes en todo aque-llo que fue necesario. Y el resultado es queahora, poco más de un año después, estásiendo ya usado nativamente2 por al menos 5suites ofimáticas que cubren las 5 plataformasmás utilizadas (según orden decreciente dedifusión: Symbian, Windows, MacOS, Linux yFreeBSD), además de varias decenas de apli-caciones más que usan algunas de sus partes(documento de texto, presentación, hoja decálculo y dibujo vectorial) o lo utilizan paraalguna funcionalidad adicional (gestión docu-mental, indexaciones, formularios, flujosoperativos, etc.)

Un factor que, sin duda, ha agilizado muchoque tantas aplicaciones ofimáticas ya exis-tentes hayan podido adoptar con facilidadOpenDocument, ha sido el que durante suespecificación se aprovecharan cuantosestándares ya existentes fueran interesantesen la medida de lo posible. Además, paramuchos de ellos ya existía mucho códigofuente libre y librerías disponibles en el mer-cado. Con ello se conseguían abaratar yagilizar las implementaciones de la especifi-cación. Así, estándares reutilizados para

OpenDocument han sido: XML, ZIP, DublinCore, SVG, XSL, SMIL, XLink, XForms,MathML, HTML, etc. Queda patente queno se ha reinventado innecesariamente nin-guna rueda. Y fiel resultado de ello es proba-blemente que su documento de especifica-ciones3 apenas supere las 600 páginas.

Pero sin duda, y aparte de sus muchas virtu-des técnicas en las que no vamos a entrar,una gran parte del interés por el formato seha debido a su ratificación como estándarinternacional ("de iure") que recibió de ma-nos de la organización ISO/IEC (InternationalOrganization for Standardization/International Electrotechnical Commission)el pasado 1 de mayo del 2006. Desde enton-ces, y aunque su publicación oficial se dilatóhasta ya entrado diciembre del 2006,OpenDocument ostenta la denominaciónoficial de ISO 26300.

Tras lograr unánimemente tal "bendición", yen un periodo de poco más de medio año, nohan sido pocos los gobiernos y entidadesoficiales que han decidido adoptarlo comosu único estándar documental. Esto entradentro de la lógica, ya que tampoco existeningún otro estándar de sus característicasque le haga de alternativa. De hecho, inclusose puede argumentar que tampoco existenecesidad para la sociedad de que lo haya.

Una equivalencia a esa apreciación seríaque, por ejemplo, tampoco hay necesidadalguna para la sociedad de que exista unaalternativa que compita con el sistema mé-trico decimal de medición, pues ya un soloestándar cumple perfectamente su misión demedir y permitir intercambiar dichas medi-das entre todas las entidades y personas, singenerar confusión innecesaria alguna debi-do a la existencia de duplicidades de siste-mas. Y para más señas remitámosnos a laestrepitosa Mars Climate de la NASA4 .

Así, casos notorios de adopción deOpenDocument han sido algunos como: elde la Administración de Massachusetts porcuanto el más sonado y conflictivo segura-mente por la gran presión política y mediáticaen contra ejercida por la comercial Microsoft;el de Bélgica para toda su administraciónfederal; la ley de estándares abiertos de Di-namarca de la mano del informe Ramboll5

sobre los ahorros que se obtendrían norma-lizando el uso de OpenDocument; la Mociónde la Junta de Extremadura en España queregula el uso exclusivo en su administración deOpenDocument y PDF/A; el anuncio del Go-bierno de Francia de migrar toda su adminis-tración a la aplicación OpenOffice.org sopor-tando OpenDocument, a la par de los resulta-dos del Informe Carayon6 ; anuncios seme-jantes por parte del Ministro de Ciencia deNoruega; migraciones masivas varias en laAdministración de Brasil; la migración ma-siva del Gobierno de Tamil Nadu en la India;la del Ayuntamiento de Zaragoza en Espa-

novática nº 184 noviembre-diciembre 200624

monografía Formato de Documento Abierto (ODF)

monografía

ña; la adopción en exclusiva por la provinciade Misiones en Argentina; la pionera norma-tiva de la Universidad de Cádiz (España)sobre intercambio de documentos electróni-cos; etc. Desde la OpenDocument Fellowship7

y desde el proyecto OpenOffice.org8 se estánmonitorizando éstas y otras adopciones masi-vas del estándar sobre todo en el sector públi-co, que es el que está más obligado, por sunaturaleza, a usar los estándares abiertos paraasí evitar discriminar a los ciudadanos en fun-ción de si son o no clientes de un determinadoproveedor privado al usar el formato exclusivode su aplicación comercial.

2.2. ¿Necesitamos un segundo están-dar? La estrategia de MicrosoftEs normal que a la hora de adoptar cualquierdecisión siempre sea imposible contentartodos los intereses. Pero, ante todo, es real-mente complicado y poco legítimo contentarintereses económicos muy particulares y que,para más inri, van en contra del bien general.

Así, la empresa que ostenta el práctico mo-nopolio de sistemas operativos de escritorioy el de aplicaciones ofimáticas con su cono-cido tandem Windows/Office, ha decididono adoptar el estándar OpenDocument quepropone prácticamente todo el resto delmercado, encontrándose inmersa en un pro-ceso de intenso lobby para conseguir laestandarización de su formato alternativo:Microsoft- Office Open XML.

Para ello dicha multinacional se ha servidode una agencia de estandarización europeacon fama de tener fáciles tragaderas: ECMA(European Computer ManufacturersAssociation). Así, por medio de un comitétécnico, presidido por ella misma y bastantereducido, en el que, además, la mayor partede sus componentes eran llegados ex professosólo para cumplir con esta tramitación9 , hahecho que el organismo le apruebe su forma-to bajo el nombre ahora de ECMA-OfficeOpen XML (EOOX). Aunque eso sí, no sinevitar el sonado voto en contra de IBM,miembro histórico de la entidad. El siguientepaso viene a ser ahora la tramitación del mis-mo como estándar internacional por ISO, yaque ECMA no deja de ser una agrupación deempresas que emiten sus estándares privadossin ningún valor oficial. Sin embargo, sonmuchas e importantes las voces surgidas encontra de duplicar formatos innecesariamentecon dos estándares10 que se solapan en sutotalidad cubriendo la misma necesidad. Igual-mente son importantes las predicciones deimportantes analistas11 en ese sentido.

Pero lo más interesante para este estudio esque la tramitación de este formato por ECMAha vislumbrado ciertos detalles que se ha-brían de tener en cuenta y que se hace nece-sario analizar con cierto detalle.

Primeramente, no se debe pasar por alto unareseña a la composición del Comité Técnico

45 de ECMA encargado de estandarizar elformato de Microsoft. En él destaca, comose ha mencionado, que solo cuatro de susmiembros lo son de ECMA (Microsoft, Intel,Toshiba y Apple) y que todo el resto sonexternos llegados ex professo al comité parallevar a cabo esta tramitación en exclusiva.

Pero más realmente significativo y desveladorresulta el objetivo declarado oficialmentepor dicho Comité a la hora de tramitar esteformato como estándar suyo. Y, sobre todo,contrasta con el abierto y ecuánime objetivoantes mencionado del Comité de OASIS quecreó OpenDocument. El propósito del co-mité ECMA no es otro que, traducido literal-mente, "producir un estándar formal paraaplicaciones de productividad ofimática quesea completamente compatible con losFormatos Office Open XML, remitidos porMicrosoft".

De esa curiosa descripción de funciones,inmediatamente llama la atención que enECMA al menos se podrían haber ahorradoel calificativo "completamente", ya que asíincluso se llegarían a albergar mínimas du-das sobre la imparcialidad y neutralidad delcometido del comité. Así, la pregunta obviaantes estas intenciones es: ¿en ese caso paraqué estaban el resto de entidades dentro delcomité, si esto era cuestión de meramenteratificar todo lo que Microsoft pusiera sobrela mesa sin discusión alguna que saliera deesa "completa compatibilidad" con la aplica-ción del proveedor declarado monopolio?Significativo ha sido por ejemplo el caso deNovell, uno de los referidos miembros exprofesso del comité, que tras un multimillo-nario acuerdo de patentes con Microsoftperfectamente legible en términos de "acuer-do de financiación", se ha autodesignadocomo quien va a desarrollar el soporte alformato EOOX para OpenOffice.org. Laidea probablemente es que de esta forma seevite la impresión de que es sólo una aplica-ción ofimática la que en el mercado lo sopor-te: la nueva versión de MS-Office de próxi-ma (y osada12 ) comercialización.

Sin embargo, no le queda una misión fácil aNovell, pues, en contraste con las apenas 7centenas de páginas de la especificación deOpenDocument, la del formato propuesto porMicrosoft y finalmente emitido por ECMAcuenta con más de 6.000 páginas a las quehabría que añadir múltiple material documen-tal de soporte... todo ello para cubrir no másque la misma funcionalidad que ODF.

Aunque lo cierto es que en realidad no hacensu función por igual, no importa si así hayasido su publicitada pretensión original. Elhecho es que uno de ellos en definitiva cum-ple la función de formato documental demanera significativamente peor que el otro.De hecho probablemente sea esa una de lasposibles explicaciones al tan desmesuradotamaño de su especificación.

3. OpenDocument vs. ECMA-OfficeOpen XML (EOOX)

Ante la comparativa de los dos formatos loprimero que resalta son los distintos propó-sitos de cada comité de estandarización quelos ha emitido. Como se ha mencionado,mientras que uno de ellos está orientado atoda la industria en general con nadie enparticular como referencia ni preferencia, elotro, está orientado exclusivamente a sercompatible con una aplicación concreta pro-piedad exclusiva de la empresa creadora delmismo y, lo que es más, probablemente os-tentando el solo propósito de continuarmanteniendo en la cautividad a los actualesusuarios de sus aplicaciones.

De hecho ha llegado a exigirse tal término decompatibilidad con la aplicación MS-Officeque el EOOX detalla en su especificaciónincluso errores históricos perfectamente co-nocidos y no corregidos de la misma13 . Pro-bablemente ésta sea una de las pocas vecesen la historia que una entidad de estandari-zación no depura los errores conocidos deun formato o protocolo a la hora deestandarizarlo, y, muy al contrario, los con-sagra para que todo el resto de implemen-tadores de la especificación también se veanobligados a artificialmente reproducirlos ensus respectivas aplicaciones. Nos encontra-ríamos así ante la típica situación que seplantea cuando alguna entidad dominantetiene un problema. Ésta dispone de dos for-mas de evitar sus repercusiones negativas,que es lo que en realidad le molesta, no elproblema en sí. La primera opción seríaresolver el problema sin más, mientras que,por contra, la segunda sería exportarlo atoda la competencia para que nadie tengaventaja, aunque esto sea en detrimento de laexperiencia de los usuarios.

Otro hecho es que la especificación de EOOXen la mayor parte de los casos reinventa larueda evitando reutilizar estándares ya exis-tentes para cubrir funcionalidades que in-cluye. Probablemente esto se hace de formainteresada, pues es la vía de ocasionar unesfuerzo e inversión añadidos a la compe-tencia, mientras que Microsoft, que ya dis-pone de la aplicación funcionando de esaheterodoxa forma, no tiene que afrontarsobreesfuerzo alguno.

Como ejemplo significativo se puede citar elcaso de los hiperenlaces, para los que no utilizael muy extendido y común estándar XLink,llegando así a codificarlos de esta singular ycríptica manera:

<w:hyperlink w:rel=»rId1"

w:history=»1">

<w:r>

<w:t>Esto es un hiperenlace</

w:t>

</w:r>

</w:hyperlink>

novática nº 184 noviembre-diciembre 2006 25

Formato de Documento Abierto (ODF) monografía

monografía

Siendo necesario ir a buscar el hiperenlaceen cuestión a otro fichero adicional.

OpenDocument por contra está mucho máshecho a la medida humana y usa el estándarXLink. Comparemos lo anterior con el mis-mo hiperenlace según lo codificaOpenDocument:

<text:a xlink:href=»http://ejemplo.com»>

Esto es un hiperenlace

</text:a>

Ejemplo de esta reutilización de todo lo posibleexistente y útil es que OpenDocument resultabastante equivalente y fácil de implementarpara cualquier programador que conozcaXHTML, DocBook o incluso HTML. EOOX,por contra, lo codifica todo de una formaabsolutamente distinta y críptica, muy difícilde entender para cualquier profesional y, loque es peor, prácticamente imposible de tradu-cir a otro formato estándar como el propioXHTML u OpenDocument. De ahí viene lasospecha relativamente fundada de que EOOXes simplemente una traducción a XML de lossecretos formatos binarios hasta la fecha utili-zados por Microsoft, que no dejaban de sersimples y tecnificadísimos volcados de la re-presentación del documento en la memoria dela aplicación MS-Office. Esto es, aptos para lamáquina, pero no para el humano. Algo seme-jante a programar en ensamblador una granaplicación informática.

Dicha apreciación se puede corroborar ob-servando los distintos modos de codifica-ción XML que usan cada una de ellas. Mien-tras que OpenDocument adopta un modoXML de "contenidos mezclados" propio delos contenidos no estructurados (como sonlos documentos de texto), EOOX se organi-za el interior de sus ficheros en un modo de"contenidos sin mezclar" más propio de ba-ses de datos y de formatos de datosestructurados. Explicado más detalladamen-te, en un documento XML se pueden dar dostipos de entradas: etiquetas y textos; y dentrode la apertura y cierre de una etiqueta sepueden incluir otras tanto otras etiquetascomo texto. Así, en el modo de contenidosmezclados, dentro de la apertura y cierre deuna etiqueta se pueden incluir tanto másetiquetas como texto indistintamente. Porcontra, en el modo de contenidos sin mez-clar, dentro de una etiqueta sólo se puedeincluir o más etiquetas o texto, pero noambos.

Veamos qué implica esto en la representa-ción de un mismo texto pequeño paraOpenDocument y para EOOX. Primeramen-te el texto original con su formato según loqueremos representar:

Esto es un documento muysimple con un poco deformato y un hiperenlace.

Y el hiperenlace, que no se ve en el ejemplo,apuntaría a la URL <http://www.estandaresabiertos.com/>.

Así, OpenDocument representaría este textoasí:

<text:p text:style-name="Standard">

Esto es un

<text:span text:style-name="T1">documento</text:span>

muy simple

<text:span text:style-name="T2">con un poco de</text:span>

formato y un

<text:a xlink:href="http://www.EstandaresAbiertos.org">hiperenlace</

text:a>

</text:p>

que como se observa, incluso podríamodificarse a mano usando un editor detexto de cualquier terminal de texto, pues esbastante inteligible para una persona conmínimos conocimientos de HTML, XHTMLo Docbook.

Por contra, obsérvese la codificación que deese mismo texto hace EOOX:

<w:p> <w:r> <w:t>Esto es un </w:t> </w:r> <w:r> <w:rPr> <w:b /> </w:rPr> <w:t>documento</w:t> </w:r> <w:r> <w:t> muy simple </w:t> </w:r> <w:r> <w:rPr> <w:i /> </w:rPr> <w:t>con un poco de</w:t> </w:r> <w:r> <w:t> formato y un </w:t> </w:r> <w:hyperlink w:rel="rId4"w:history="1"> <w:r> <w:rPr> <w:rStyle w:val="Hyperlink"/> </w:rPr> <w:t>hiperenlace</w:t> </w:r> </w:hyperlink></w:p>

Se comprueba que difícilmente alguien po-drá, no ya cambiar a mano, sino siquierainterpretar con cierta agilidad la representa-ción de un texto tan simple como el anterior.

Pero no solo proviene la cripticidad de EOOXpor este modo de codificar el XML, también

se deriva de codificaciones que tienen suorigen directa y específicamente en cómo lossistemas operativos de Microsoft, losWindows, almacenan la información en sumemoria. En el siguiente ejemplo, entresa-cado de la sección 2.8.2.16 (página 759) delVolumen 4 del borrador final de EOOX, sepuede encontrar la siguiente expresión me-dio XML medio binaria:

<w:font w:name="Times New Roman">

<w:sig w:usb0="2002A87" w:usb1=

"80000000" w:usb2="00000008"w:usb3="00000000" w:csb0="000001FF"

w:csb1="00000000" />

...

</w:font>

Como se puede advertir, los númeroshexadecimales asignados a las variables "usb"y "csb" son meros volcados bit a bit de lasestructuras de datos en memoria de Windowsque no han pasado por abstracción algunaque los haga aptos para otras plataformas nimínimamente inteligibles a un más alto ni-vel. ¿Acaso no habíamos quedado en queEOOX era un formato XML puro? ¿No sehabía ya llegado al consenso de que losformatos binarios eran cosa del pasado másoscuro del software? Pero lo más grave esque este tipo de codificaciones binarias ydependientes de plataforma (por ejemplo¿sólo para los sistemas big-endian o porcontra para los little-endian?) se repiten paradistintas funcionalidades de EOOX comoson: formato condicional de párrafo, forma-to condicional de casilla de tabla, formatocondicional de fila de tabla, excepción deparámetros de formatos condicionales deestilo de tablas, etc. Se puede leer muchomás sobre esta materia de las máscaras debits en EOOX en un artículo escrito porprofesionales de IBM14 .

Y aún hay más, en las especificaciones seexige tener en cuenta formas de funcionar yexcepciones, que ni siquiera están descritas ysólo son conocidas por Microsoft, de lasdistintas versiones que han existido de laaplicación MS-Office en combinación conlas a su vez sucesivas versiones de MS-Windows en las que han funcionado16 . Pro-bablemente los títulos de los capítulos dealgunas de estas joyas de anticuario, segúnaparecen en las especificaciones oficiales deEOOX, ya son lo suficientemente autodes-criptivos:

autoSpaceLikeWord95 (Emulate Word95 Full-Width Character Spacing) – capítu-lo 2.15.3.6.

footnoteLayoutLikeWW8 (EmulateWord 6.x/95/97 Footnote Placement) – ca-pítulo 2.15.3.26.

mwSmallCaps (Emulate Word 5.x forthe Macintosh Small Caps Formatting) –capítulo 2.15.3.32.

suppressTopSpacingWP (EmulateWordPerfect 5.x Line Spacing) – capítulo2.15.3.51.

novática nº 184 noviembre-diciembre 200626

monografía Formato de Documento Abierto (ODF)

monografía

lineWrapLikeWord6 (Emulate Word 6.0Line Wrapping for East Asian Text).

mwSmallCaps (Emulate Word 5.x forMacintosh Small Caps Formatting).

shapeLayoutLikeWW8 (Emulate Word97 Text Wrapping Around Floating Objects).

truncateFontHeightsLikeWP6 (EmulateWordPerfect 6.x Font Height Calculation).

useWord2002TableStyleRules (EmulateWord 2002 Table Style Rules).

useWord97LineBreakRules (EmulateWord 97 East Asian Line Breaking).

wpJustification (Emulate WordPerfect 6.xParagraph Justification).

shapeLayoutLikeWW8 (Emulate Word97 Text Wrapping Around Floating Objects).

A la vista de estos pocos ejemplos a buenseguro que se entiende mucho mejor lasrazones por las que la especificación deEOOX ocupa más de 6.000 páginas sin con-tar anexos.

Adicionalmente, otro problema de diseño queplantea la codificación de EOOX con respectoa OpenDocument es que mezcla mucho elpuro contenido con la presentación del mismo.Por contra, OpenDocument, aunque no selibra, lo hace en mucha menor medida, mante-niendo ambas informaciones en lugares distin-tos en la mayoría de los casos.

Esa separación sería el equivalente a la ma-nera en que se lleva a cabo la codificación enXHTML con los ficheros CSS de presenta-ción. Veámoslo como ejemplo el siguientetexto formateado y sus dos formas de repre-sentarlo en cada formato:

texto en negritastexto en negritastexto en negritastexto en negritastexto en negritas

Para su representación en OpenDocumentpor un lado se almacena la informaciónreferente a los contenidos:

<text:span text:style-name="Enfasis

_10_Negrita">

texto en negritas

</text:span>

Y por otro se codifica la forma de presentaresos contenidos donde, como se observa, sedefine el estilo usado "Negrita_20_Enfasis":

<style:style style:name= "Enfasis_10_Negrita" style:display-

name="Enfasis con Negrita" style:family="text">

<style:text-properties fo:font-weight="bold" />

</style:style>

Se observa que OpenDocument está usando"estilos" para darle formato al documento.Esto tiene un importante uso sobre todo a lahora de modificar la presentación de todo undocumento, pues sólo es necesario cambiarel estilo, y no hay obligación de navegar portodo el documento cambiando el aspecto

texto por texto aparición por aparición.Por contra EOOX codifica este mismo textoy formato de la siguiente forma:

<w:r>

<w:rPr>

<w:b />

</w:rPr>

<w:t>texto en negritas</w:t>

</w:r>

En ella se puede observar la peculiaridad demezclar contenidos con formato, ya que<w:b /> significa "negritas".

Siguiendo con el análisis técnico de ambosformatos, si abordamos una comparativa detamaño de los ficheros y de los elementos delos mismos17 que se requieren para almace-nar un mismo texto de unas dimensionesapreciables, se desvela que OpenDocumentgenera ficheros alrededor de un 90% meno-res que los equivalentes en el antiguo forma-to .doc de Microsoft, y cerca de un 50%menores que los ficheros generados por elformato EOOX.

Por otro lado, los análisis económicos de losesfuerzos necesarios para implementar lamastodóntica especificación del formatopropuesto por Microsoft también dejan veruna gran diferencia con respecto aOpenDocument. Un empleado de la propiamultinacional en su división Mac estimaba18

un esfuerzo de 5 desarrolladores-año paraprogramar sólo una cuarta parte de lo necesa-rio para el procesador de textos nada más. Porotro lado, un experto de Adobe estimaba19 losesfuerzos para implementar toda la especifica-ción en 150 desarrolladores-año. Por último, elvicepresidente de la OpenDocumentFoundation estimaba20 en 1.000 dólares sóloel coste de impresión del material documentalnecesario para su implementación.

Otro problema grave que se presenta a lahora de implementar o adoptar EOOX esque no existe garantía alguna de que niMicrosoft ni ninguno de los otros miembrosdel comité técnico de ECMA hayan, no yarenunciado sino, siquiera anunciado las pa-tentes de software que infringe el formato21 .Esto lleva al ya conocido riesgo de la deman-da de forma postergada a todas las otrasaplicaciones que lo adopten, pero, claro,sólo una vez que el estándar ha logradosuficiente difusión tal y como ocurrió en elcaso de Unisys y GIF22 .

De hecho la licencia de Microsoft no licenciatodas las patentes suyas necesarias paraimplementar por completo el formato23 . Porsuerte para los europeos las patentes de soft-ware no son legales, pero probablemente nopuedan decir lo mismo los ciudadanos y em-presas de otros países comenzando por EE.UU.Y obviamente hay que tener en cuenta que losestándares internacionales han de cubrir unámbito mundial, y no tiene sentido que su uso

sea restringido a una región concreta mientrasse pretende denominarlos, o darles el falsocarácter, de "internacionales".

Cerrando ya la enumeración de factores de lacomparación entre formatos, es necesario te-ner en cuenta otro últimamente muy importan-te y controvertido. Partamos de la benignasuposición de que el formato EOOX está librede patentes y es implementable por cualquieracon absoluta libertad independientemente delas considerables dificultades que para ello yase han descrito. Sin embargo, hasta ahora eneste análisis no se han tenido en cuenta unfactor clave: los DRM24 (Digital RightManagement o mejor denominados DigitalRestrictions Management -"gestión de restric-ciones digitales"-).

Para Microsoft y su monopolio no ha desuponer mayor problema el hecho de abrirsus formatos si después puede cerrarlos por-que los documentos generados en sus siste-mas operativos queden sujetos a claves deliberación DRM que son imposibles de leerpor otras plataformas y que, de hecho, hastaresulte ilegal decodificarlas según leyes nor-teamericanas25 y europeas26 . Y WindowsVista conjuntamente con MS-Office 12 in-corpora plenamente los DRM y las claves deliberación27 que atan los contenidos a seraccedidos exclusivamente por hardware ysoftware determinados.

Ya por último, es obligatorio mencionar elmayor punto que actualmente juega en con-tra de EOOX. Éste es que, tras poco más deun año de desarrollo, comparativamente alos más de 5 de OpenDocument, EOOX nocuenta en el mercado, a día de hoy, conninguna aplicación que lo soporte. De he-cho, ni siquiera la propia de su auspiciadory promotor, Microsoft, está aún disponiblecomercialmente. Por ahora es sólo una pro-mesa: mero vaporware28 .

4. ConclusionesAnte los extensos hechos citados perfecta-mente caben muchas disyuntivas: ¿se debe,pues, volver a los tiempos en que las entida-des de estandarización generaban entelequiasteóricas prácticamente imposibles de llevara la práctica? Es más, ¿se debe volver sólopara satisfacer los intereses comerciales deuna empresa declarada monopolio por lasautoridades de los dos mayores mercadosmundiales? ¿Acaso no se había superado yaese error del pasado?

¿Qué sentido tienen especificaciones de mi-les y miles de páginas que solo son el reflejode la forma de hacer las cosas de una aplica-ción y empresa concretas, y que es práctica-mente imposible o impracticable, que pue-dan ser legítimamente soportadas por otrasaplicaciones competidoras? ¿Se pretendedisponer y garantizar mercados libres dondela competitividad baje los precios e incentivela innovación, o, por contra, es cuestión de

novática nº 184 noviembre-diciembre 2006 27

Formato de Documento Abierto (ODF) monografía

monografía

seguir todos sujetos a una sola aplicaciónguiados por los fútiles intereses de un únicofabricante gracias a sus patentes, DRM, in-gentes especificaciones, etc.?

A favor de EOOX frente a ODF ni siquiera sepueden argumentar bondades técnicas se-gún se ha comprobado en la comparacióndel anterior capítulo. De hecho, y como biense menciona en la web de la OpenDocumentFellowship, aún resta por darse a conocer unsolo ejemplo de algo que sea capaz de hacerEOOX y que OpenDocument no pueda. Unosólo.

Por último, no tiene sentido que a estasalturas del siglo XXI los poderes públicosplanteen la duplicación de los estándarescuando prácticamente nadie, salvo una em-presa concreta, obtiene beneficio alguno conesa medida. Sería como querer volver areintroducir las millas turcas para que elsistema métrico tuviera competencia. ¿Aca-so necesita competencia el sistema métricodecimal? Más bien no.

Los estándares abiertos oficiales que cumplencorrectamente su misión, comoOpenDocument lo hace, no deben ni necesitantener innecesarias alternativas, sino que porcontra deben ser exigidos y promovidos por lospoderes públicos. Donde debe producirse com-petencia y facilidades de elección es entre losfabricantes y sus aplicaciones, no entre losestándares de más que suficiente calidad. ¿Quénecesidad hay de generar errores, caos y desen-tendimiento donde existe una magnífica y pro-ductiva armonía?

Todas estas conclusiones se observan en laposición de respaldo de la práctica totalidaddel mercado ofimático a OpenDocument.Este es el mejor reflejo de lo que ha de ser elfuturo de los formatos documentales elec-trónicos para la Humanidad: estándaresabiertos, universales y libres, como puedanser los alfabetos, los idiomas o la técnicashistóricas de fabricación del papel que hanpermitido que recibamos el conocimiento denuestros ancestros.

Por contra, ECMA/MS-Open Office XMLsólo trae una prolongación innecesaria deun cautivismo a los formatos y aplicacionesde ciertas empresas concretas y únicas encada momento histórico, independientemen-te de la mucha o poca cuota de mercado quehayan tenido, o de si son o han sido o nomonopolios. De ahí que la posible estandari-zación internacional de EOOX y su triunfoen el mercado sólo implicarían el hecho deseguir sumidos en la Edad Media de ladocumentación electrónica. Continuarinmersos en aquellos tiempos en que la Hu-manidad sufría el secuestro y censura de suconocimiento en manos de unos pocos no-bles feudales con unos derechos especialesvetados al resto de los mortales. Resumien-do, uno de los peores bloqueos que podría

sufrir el desarrollo de la Sociedad de laInformación. En definitiva, son las aplica-son las aplica-son las aplica-son las aplica-son las aplica-ciones las que se deben ajustar a losciones las que se deben ajustar a losciones las que se deben ajustar a losciones las que se deben ajustar a losciones las que se deben ajustar a losestándaresestándaresestándaresestándaresestándares, no al contrario. La Humanidad La Humanidad La Humanidad La Humanidad La Humanidadya tiene un estándar documental. ya tiene un estándar documental. ya tiene un estándar documental. ya tiene un estándar documental. ya tiene un estándar documental. Su nom-bre es ISO 26300, OpenDocument.OpenDocument.OpenDocument.OpenDocument.OpenDocument.

AgradecimientosMi agradecimiento a Alex Hudson, J. DavidEisenberg, Bruce D’Arcus, Daniel Carrera y Mar-co Fioretti (OpenDocument Fellowship), a RobWeir y Bob Sutor (IBM), a Simon Phipps y TimBray (Sun Microsystems), a Marino Marcich(ODF Alliance), Sam Hiser (OpenDocumentFoundation), a Rafael Rodríguez (Universidad deCádiz) y a todos aquellos que mi memoria traicio-na, sin cuyos continuos esfuerzos en el estudio yla promoción de de los formatos documentalesabiertos no hubiera sido posible este artículo.

Notas

1 Comité OpenDocument de OASIS creado en no-viembre del 2002. <http://www.oasis-open.org/committees/office/charter.php> (último acceso 200-12-29).2 Aplicaciones informáticas que soportan OpenDocument o lo usan nativamente según la OpenDocument Fellowship. <http://www. opendocumentfellowship.org/applications> (último acceso 2006-12-29).3 Especificación de OpenDocument por OASIS. <http://www.oasis-open.org/committees/download.php/19275/OpenDocument-v1.0ed2-cs1.odt> (últimoacceso 2006-12-29).4 El Mundo: "La ‘Mars Climate’ estalló al fallar la medición".< http://www.elmundo.es/1999/10/02/sociedad/02N0058.html> (último acceso 2007-01-15).5 Gobierno de Dinamarca: "Informe Ramboll" de cál-culo de ahorros al implantar OpenDocument frente aMS-Office Open XML. <http://www.osl.dk/upload-mappe/ram_engPDF/ >(último acceso 2006-12-29).6 Gobierno de Francia: "Informe Carayon" con cálculode ahorros en la implantación de OpenDocument.<http://www.ladocumentation francaise.fr/rapports-publics/064000728/index.shtml >(último acceso2007-01-10).7 OpenDocument Fellowship: precedentes de adop-ción de OpenDocument en el mundo. <http://www.opendocumentfellowship.org/government/precedent> (último acceso 2006-12-29).8 OpenOffice.org: seguimiento de cuota de mercado.<http://wiki.services.openoffice.org/wiki/Market_Share_Analysis> (último acceso 2006-12-29).9 ECMA: Presentación "ECMA TC45 – Office OpenXML Formats" (página 16). <http://www.ecma-international.org/activities/Office%20Open% 20XML%20Formats/TC45_GA_Dez05.pdf >(último acce-so 2007-01-10).10 Comisión Europea, "PEGSO Conclusions andRecommendations on Open Document ExchangeFormats", 6-dic-2006. < http://europa.eu.int/idabc/en/document/3439 >.11 Informe en el que Gartner Group predice que elformato de Microsoft no será estandarizado por ISO.<http://www.gartner.com/resources/140100/140101/iso_approval_of_oasis_opendo_ 140101.pdf> (último acceso 2006-12-29).12 Wall Street Journal, "Bold redesign improvesMicrosoft Office 2007", donde Microsoft es calificadode "osado" por el alto coste de formación que conlle-varán los significativos cambios en el interfaz deusuario que incorpora el nuevo MS-Office. <http://www.moneyweb.co.za/shares/international_ news/

553820.htm> (último acceso 2007-01-10).13 MS-Excell contiene un error en el cálculo secuencialde los días del calendario porque parte de la falsapremisa de que el año 1900, origen de su cálculo, esun año bisiesto. La especificación de ECMA-OfficeOpen XML consagra este error y obliga a suimplementación para cumplir con la misma. Másinformación en Rob Weir "A Leap Back". <http://www.robweir.com/blog/2006/10/leap-back.html>(último acceso 2006-12-29).14 An Antic Disposition, Rob Weir, "A bit about the bitwith the bits". <http://www.robweir.com/blog/2006/10/bit-about-bit-with-bits.html>(último acceso 2007-01-10).15 KDE Developer Journals, Zander, "office documentformats". <http://www.kdedevelopers.org/node/2568> (último acceso 2007-01-10).16 Rob Weir, "To hire Guillaume Portes". <http://www.robweir.com/blog/2006/01/how-to-hire-guillaume-portes.html> (último acceso 2007-01-10).17 O’Reilly XML.com: "Comparing XML office documentformats: using XML metrics". <http://www.oreillynet.com/xml/blog/2006/08/comparing_xml_office_document_3.html >(último acceso 2007-01-10).18 Estimación de esfuerzos para implementación deEOOX por Rick Schaut de Microsoft: "Open XMLconverters for Mac Office". <http://blogs.msdn.com/rick_schaut/archive/2006/12/07/open-xml-converters-for-mac-office.aspx >(último acceso2007-01-10).19 Estimación de esfuerzos para implementación deEOOX por Andrew Shebanow de Adobe: "Is OfficeOpen XML an one-way standard? Ask Microsoft.<http://blogs. adobe.com/shebanation/2006/12/open_xml_one-way.html>(último acceso 2007-01-10).20 Information Week: "Microsoft’s XML Standard NeedsFast Track Approval To Halt Defections", con comen-tario de Sam Hiser. <http://www. informationweek.com/management/showArticle. jhtml?articleID=196602114> (último acceso 2007-01-10).21 Análisis de Groklaw sobre los derechos de propie-dad intelectual e industrial de ECMA Open Office XML.<http://www.groklaw.net/articlebasic.php?story=20051207020812228> (último acceso 2006-12-29).22 Unisys exige pagos a todos los usuarios del formatode imágenes GIF. Explicación de la FSF. <http://www.gnu.org/philosophy/gif.html>(último acceso2006-12-29).23 Sam Hiser, "Analyzing the Microsoft Office OpenXML license". <http://fussnotes.typepad.com/plexnex/2007/01/analyzing_the_m.html> (últimoacceso 20070115).24 Wikipedia, DRM. <http://es.wikipedia.org/wiki/Gesti%C3%B3n_de_derechos_digitales> (último ac-ceso 2007-01-10).25 EEUU, Digital Milenium Copyright Act (DMCA) enanálisis de la EFF. <http://www.eff.org/IP/DMCA/>(último acceso 2007-01-10).26 EU, Directiva 2001/29/EC "sobre armonización deciertos aspectos del copyright y ciertos derechos enla sociedad de la información" según Wikipedia.<http://en.wikipedia.org/wiki/Directive_ on_the_harmonisation_of_certain_ aspects_ of_copyright_and_related_rights_in_ the_ information_society>(último acceso 2007-01-10).27 Jeff Farris, "Remote Attestation". <http://www.math.uiuc.edu/%7Eduursma/Math595CR/FarJ.pdf> (último acceso 2007-01-10).28 Daniel Eran, "Microsoft’s yellow road to Cairo". <http://roughlydrafted.com/RD/Q4.06/4E2A8848-5738-45B1-A659-AD7473899D7D.html> (últimoacceso 15-01-2007).

novática nº 184 noviembre-diciembre 200628

monografía Formato de Documento Abierto (ODF)

monografía

"Lo que dan con la letra grande lo quitan con laletra pequeña"

Tom Waits (Small Change, 1976)

1. IntroducciónNos encontramos en una encrucijada en loque se refiere a estándares, con la conec-tividad futura de ordenadores de sobremesa,dispositivos y sistemas de empresa comorecompensa. Hay dos implementaciones deXML (eXtensible Markup Language) quepueden abarcar los horizontes de este uni-verso emergente y el mundo está esperandoa ver cuál de ellas prevalece.

Es tiempo de decidir.

Presentemos a nuestros dos contendientes:OpenDocument FormatOpenDocument FormatOpenDocument FormatOpenDocument FormatOpenDocument Format (ODF) y ECMAECMAECMAECMAECMAOffice Open XMLOffice Open XMLOffice Open XMLOffice Open XMLOffice Open XML (EOOXML) de Microsoft(N. del T.N. del T.N. del T.N. del T.N. del T.: ECMA es la European ComputerManufacturers Association). Microsoft de-clara que son interoperables, con lo que lapromesa de XML de una transformaciónfluida se habría alcanzado. Sin embargo, lospartidarios de ODF no piensan lo mismo;ODF es el único formato universal de fiche-ros que vale la pena tener en cuenta.

No hay necesidad de tomar una decisión, insis-te Microsoft. Si Vd. está haciendo uso deaplicaciones Microsoft y ejecuta EOOXML,entonces este formato es su opción. Si Vd. esuno de los 485 millones de usuarios deMicrosoft Office para Windows, encadenadosdurante décadas a ficheros binarios hereda-dos, y construye sus procesos de negocio dia-rios sobre estos ficheros, entonces EOOXMLes para Vd.. Y sólo EOOXML.

Si Vd. está haciendo uso de cualquier otrotipo de aplicación, entonces ODF es su me-jor elección. Microsoft está encantado deconsentir la elección entre estos dosestándares de documentos [sic] ya que, mien-tras nosotros estamos hablando, Microsoftestá trabajando en conseguir la interopera-bilidad entre los dos formatos. Después detodo, tanto ODF como EOOXML son XML.¿Verdadero?

¡Falso! Y ahí radica el cuento sobre unadecisión que determinará el futuro. Lainteroperabilidad y la transformación senci-lla son el distintivo de XML. Pero no es estolo que está sucediendo aquí.

Microsoft, por supuesto, hará todo lo posi-ble para hacer creer que el sueño de lainteroperabilidad se ha hecho ya realidad,incluyendo el fraude de la firma de un elabo-rado conjunto de acuerdos con un débilproveedor de Linux y OpenOffice para de-mostrar que Microsoft está comprometido acumplir los requerimientos del usuario. Si loexamina detenidamente verá que el únicorequerimiento del usuario en el que Microsoftse centra es en la extensión al nuevo mundode Internet, XML y SOA (Service OrientedArchitecture) de las viejas característicaspropietarias de sus documentos. Si da unpaso atrás y tiene en cuenta todo lo anterior,se dará cuenta de que el objetivo último esextender el monopolio de los ordenadores desobremesa a los servidores, dispositivos ysistemas de información globalmente co-nectados. Esta vez juegan con todas lascartas.

¿Hay problemas legales y técnicos de impor-tancia en determinadas secciones del acuer-do de compartición de tecnología entreMicrosoft y Novell? Sin lugar a dudas, sí.Cada grupo de interesados tiene diferentesreservas sobre distintas facetas del acuerdo.Los desarrolladores de software libre y losque se acogen a la licencia GPL (GeneralPublic Licence) se ven afectados negativa-mente por el acuerdo de no litigación sobrepatentes; la competencia formada por losdistribuidores de Linux y los desarrolladoresde software libre está comprensiblementeirritada con la espuria protección de paten-

tes así como con acuerdos cruzados devirtualización y de colaboración en ventas;mientras que los usuarios y los gobiernosestán verdaderamente preocupados por silos acuerdos de ‘interoperabilidad’ estable-cidos entre Novell y Microsoft sobre el pa-quete Office pudiesen limitar sus opciones.

Hoy día nuestras preocupaciones se centran enla letra pequeña de este último aspecto delacuerdo Microsoft-Novell y en situar el asuntoen el contexto más amplio de la ISO(International Organization forStandardization), la SOA y el futuro de lasaltamente avanzadas y extremadamente pro-ductivas cadenas de proceso de la informaciónen las que se incluyen ordenadores de sobre-mesa, servidores y dispositivos.

Office Open XML ("El proyecto conjuntointerempresarial para desarrollar un meca-nismo para facilitar la conversión entre fi-cheros OpenDocument, ODF, y ficherosMicrosoft/ECMA, EOOXML") está llenode problemas. Se presenta a sí mismo comouna solución de ‘interoperabilidad’ entreMicrosoft Office y OpenOffice.org. Y no loes1 . Incluso a primera vista, la especificaciónde Microsoft para EOOXML tiene gravesdefectos y es imposible de implementar en sutotalidad por quienes no sean desarrolladoresde Microsoft. Por lo que tiene serios proble-mas para ser aceptada por la ISO comoestándar internacional. Pero sólo con enten-der algunos de los serios problemas deEOOXML, se descubre claramente el carác-

Interoperabilidad:¿se impondrá el verdadero

formato universal de ficheros?

Sam Hiser, Gary EdwardsOpenDocument Foundation

<{sam.hiser, gary.edwards}@opendocument.us><{sam.hiser, gary.edwards}@opendocument.us><{sam.hiser, gary.edwards}@opendocument.us><{sam.hiser, gary.edwards}@opendocument.us><{sam.hiser, gary.edwards}@opendocument.us>

Traducción:Traducción:Traducción:Traducción:Traducción: Rafael Fernández Calvo (Grupo de Trabajo de Lengua e Informática de ATI)

Resumen: en este artículo se comparan las dos soluciones que se enfrentan para convertirse en elestándar de formato universal de ficheros: ODF (OpenDocument Format), de la OpenDocumentFoundation, y EOOXML (ECMA Office Open XML) de Microsoft. Ambas están basadas en XML (eXtensibleMarkup Language) y se analizan tanto desde un punto de vista técnico como en su repercusión futurasobre las empresas, teniendo en cuenta principalmente su interoperabilidad real y su capacidad paraobtener la mayor fidelidad posible en la conversion de ficheros heredados.

Palabras clave: conversion de ficheros, EOOXML, estándares, formato universal, interoperabilidad,ODF, XML.

Autores

Sam Hiser es Vicepresidente y Director de Negocio de la OpenDocument Foundation. Posee un MBA porla Universidad de Duke. Fue director del proyecto de Marketing de OpenOffice.org y junto a Tom Aldelsteines el autor del libro "Exploring the JDS Linux Desktop". Contribuye regularmente a la sección "DigitalBusiness" (Negocios Digitales) del Financial Times.

Gary Edwards es el Presidente de la OpenDocument Foundation y socio fundador del Comité Técnicodel OASIS Open Office XML. Radicado en Redmond (California), es Consultor Tecnológico especialistaen el diseño e implantación de soluciones de reingeniería de procesos de negocio.

novática nº 184 noviembre-diciembre 2006 29

Formato de Documento Abierto (ODF) monografía

monografía

ter de acción subrepticia contra la libre com-petencia que tienen este proyecto de‘interoperabilidad’ y el acuerdo entreMicrosoft y Novell.

2. Migrando a XML ficheros here-dados de MicrosoftTodo el mundo está de acuerdo en que XML esciertamente el formato de documentos del próxi-mo futuro. XML es tanto el futuro de Internetcomo el núcleo central de cualquier SOA. Nosólo es "el futuro", sino también el puente entreel lugar en el que estamos hoy (la infraestruc-tura que hemos heredado) y lo que necesita-mos hacer para llegar a ese futuro.

Microsoft quiere ‘tirar’ de los clientes hacia suversión propietaria de XML (hablar de "XMLpropietario" es indudablemente una incon-gruencia, pero dejaremos esto a un lado porahora); la comunidad ODF quiere conseguirque todos usemos su implementación univer-sal y portable de XML; y los clientes estánclaramente confundidos ya que la opción deMicrosoft parece aceptable, aunque cara.

Además, la decisión de no decidirse entreEOOXML y ODF — ya que ambas opcionesson aceptables — no pondría en peligro elpuesto de trabajo de un Director de Sistemasde Información. Dando por hecho que la genteconfía en Microsoft, y mientras que la genteesté de acuerdo en que Microsoft sólo se pre-ocupa de los intereses de los clientes (como decostumbre), esta decisión de no decidirse pare-ce segura. Incluso si la gente se mantieneescéptica acerca de los motivos de Microsoft,existe la bien arraigada creencia de quedecantarse por Microsoft es simplemente in-evitable, debido al poder del aparato comercialdel monopolista en el mercado. Y, por otrolado, la opción de ODF (aunque lleve dos añosde adelanto en el proceso de estandarizaciónde la ISO) sigue pareciendo poco articulada yle falta integración en la cadena de procesos denegocio. Parece razonable.

Pero ocurre que ODF es creíble y ofrece aquienes la adopten primero (en particularAdministraciones Públicas) algunos benefi-cios realmente interesantes en lo que se refie-re a acceso perpetuo a la información, bajocoste y nueva flexibilidad en la adquisiciónde sistemas (ver más detalles sobre la SOAmás adelante). Estos beneficios se hacenrealmente evidentes para una organizacióncuando ha conseguido realizar un procesode migración de forma satisfactoria y empie-za a crear documentos en una implemen-tación abierta basada en XML.

Los argumentos a favor de ODF los entien-den perfectamente quienes se han compro-metido con este formato (ellos saben quié-nes son). Ahora bien, están preocupadossobre todo por: a) cómo consigo pasar aODF mis documentos Microsoft heredados;

b) cómo puedo gestionar formatos mixtos ysistemas mixtos durante e incluso muchodespués del proceso de transición que harealizado mi organización; c) cómo puedoresolver las irregularidades introducidas enlos procesos normales de negocio por latravesía de documentos a través de diferen-tes sistemas tanto dentro como fuera de miorganización; y d) cómo puedo hacer uso dedocumentos de estándares abiertos XMLpara separar mis desarrollos de las APIs(Application Program Interfaces) de la capaaplicativa — en particular de las que sonpropiedad de una empresa sociópata cono-cida por lanzar una segunda colección delibros acerca de sus propias APIs?

Por esto es por lo que la palabra ‘interope-rabilidad’ está en boca de todos. Con XML enel horizonte, todos los consumidores estánmartilleando a Microsoft y a la comunidadODF para que resuelvan los problemas deincompatibilidad de formatos de fichero quehan afectado al comportamiento de los docu-mentos tanto dentro como fuera de la familiade formatos ofrecida por Microsoft. Por con-siguiente, Microsoft se ha enamorado de lapalabra ‘interoperabilidad’ pero no de las ac-ciones necesarias para alcanzarla.

El mandato emitido por los consumidores esque quieren que tanto los servidores comolos dispositivos de los sistemas se integrencompletamente con aplicaciones de escrito-rio Windows | Microsoft Office. Al hablarde integración se refieren exactamente a quequieren un formato abierto de ficheros XMLindependiente de la aplicación, y de la plata-forma, capaz de conectar las aplicaciones desobremesa MSOffice tanto al servidor comoa los dispositivos de los sistemas. Resumien-do, los consumidores de tecnologías de lainformación quieren una propiedad comple-ta y clara sobre su información y sobre elprocesamiento de ésta, control sobre la in-formación diaria y los procesos de negocioen los que se basan sus flujos de trabajo y susservicios.

Pero Microsoft se muestra reacio a facilitarque los consumidores abandonen losformatos que controla. En realidad,Microsoft conoce perfectamente susformatos secretos. Perfectamente. Cualquierempresa que pueda sincronizar una conver-sión perfecta y fiel entre los miles de millonesde ficheros binarios y EOOXML, bien deforma nativa bien mediante un conector,podría también proporcionar fácilmente unafidelidad del 100% usando ODF en un plazode pocas semanas de desarrollo. Las venta-jas estructurales comparativas de ODF so-bre EOOXML son tan arrolladoras que, sino fuera por la estrategia de hacer progresary extender el monopolio, Microsoft tendríatodas las razones técnicas para elegir ODFen vez de EOOXML.

Para los consumidores ‘interoperabilidad’ sig-nifica un 100% de fidelidad en los ficheros alpasar de una aplicación a otra, tanto si son delmismo tipo como si no lo son, sin importar laplataforma subyacente. El requerimiento no escomplicado y ha sido definido claramente enMassachusetts en la petición realizada por laITD (Information Technology Division) deeste Estado para obtener información sobre unplugin ODF para MS Office.

Uno de los trabajos más tramposos que seestán realizando hoy en toda la cristiandades el empeño de Microsoft para ‘tirar’ (comoellos lo llaman de forma eufemística) de suscerca de quinientos millones de clientes ha-cia una (o dos) versión moderna y con so-porte de sus sistemas operativos, aplicacio-nes y tecnologías de formato de ficheros.Debido a sus apetitos lujuriosos, trabajoduro, liderazgo sin escrúpulos y una culturacompetitiva sociópata, la empresa ha agita-do a su clientela con tantas versiones que suprincipal competidor es ella misma. (Underivado de ese empeño principal, el de ven-der, es la necesidad de llegar a dominar lasdificultades que plantea poner fin a las ver-siones anteriores sin llamar la atención delos reguladores o sin irritar a los consumido-res más allá de un determinado punto).

Quizás sea porque Redmond siente que haforzado este juego demasiado a menudo,pero ahora estamos observando un cambiode estrategia. MSOffice 2007 es una aplica-ción de transición, muy ambidextra en elsentido de que para EOOXML tiene una APIWin32 heredada vinculada a BoBs (miles demillones de documentos binarios) y unEOOXML diferente para documentos nati-vos vinculados a la API de Vista-.Net 3.0. Dehecho, es posible tener el mismo documentoen MSOffice 2007, una versión nativa y otraheredada, con diferentes elementos internosy dependencias EOOXML. ¿Qué pasa?

Si bien nadie lo sabe con seguridad, pareceque el punto de bloqueo de clientes se hatrasladado de los documentos y procesos denegocio vinculados a Microsoft Office a unacadena de proceso de la información forma-da por MSOffice 2007<=> EOOXML<=> IE 7.0 <= > y el Exchange/SharePointHub. Es éste el hub de E/S donde se produceel nuevo bloqueo ya que todos los documen-tos EOOXML son convertidos aquí a unasdependencias basadas en la API de Vista -.NET 3.0. MS Office es sólo la cabecera deesta cadena de proceso.

Desde el hub de E/S, hay que esperar que seproduzca una acelerada conectividadEOOXML con MSLive, MSN, MS-ERP,SAP, MSSQL Servers y con los sistemas deproceso de transacciones de trastienda(backend), a Active Directory, CollaborativeServer y sistemas MSOffice Server (por citar

novática nº 184 noviembre-diciembre 200630

monografía Formato de Documento Abierto (ODF)

monografía

sólo unos pocos). Hay que esperar tambiénque el VSTO 2005 preparado para EOOXMLengrase los rieles para migrar los sistemas deproceso de negocio vinculados a MS Officeal hub E/S y alimente el rápido desarrollo deaplicaciones de negocio listas para EOOXMLy capaces de adaptarse bien a las cadenas deproceso de información dominadas porEOOXML. ¡Esto se llama integración! O,como dicen en Redmond, "Interoperabilityby Design".

Llegados a este punto, ¿tenemos que pre-guntarnos si los sistemas de software y ser-vicios competitivos no ligados a Microsoftpueden interoperar dentro de este extraordi-nario diseño de la cadena de proceso? Quie-ro decir, ¿imaginas una aplicación de escri-torio OpenOffice, o una aplicación de escri-torio MAC Office, participando en esta ca-dena? ¿Y qué hay de los servicios de combi-nación de contenidos de Google, Yahoo, oAmazon Web 2.0? ¿O del ERP, bases dedatos relacionales y sistemas de proceso detransacciones de Oracle? ¿O del Lotus No-tes de IBM? ¿O quizás del SOA de BEA?¿Entiendes ahora lo que está en juego?

Oh, sí. Adiós Adobe.

Así que, ¿de qué estamos hablando de cual-quier forma?

Interoperabilidad (la interoperabilidad ver-dadera y permanente proporcionada por unformato universal de ficheros) es importantepara procesos de negocio de todo tipo basa-dos en la forma en que la gente mueve susdocumentos a través de una amplia variedadde sistemas. El proceso de negocio de mayorrelevancia desde el punto de vista de la legis-lación antimonopolio y de los efectos sobrela competencia es el proceso de migraciónque realiza una empresa para pasar a ODFsus ficheros heredados almacenados en for-mato binario de Microsoft Office. Si se con-sigue realizar ese proceso de migración en-tonces puede decirse que es posible competircon el nuevo juego de procesos de negocio deMicrosoft. Pero si esa migración no es posi-ble Microsoft mantendrá el bloqueo sobresus clientes — no sólo en el mercado depaquetes de aplicaciones (suites), de oficinasino también en el campo de los procesos denegocio.

Sí, los BoBs de nuevo (aquellos "miles demillones de binarios"): aquellos miles demillones de documentos de Microsoft Officeheredados y almacenados en formato binario,los BoBs que Microsoft nos recuerda contanta frecuencia cuando se discute sobre laadopción de EOOXML como estándar. Elconvertidor de ficheros Novell-MicrosoftClever Age se limita a conversiones deEOOXML a ODF y no convierte directa-mente entre ODF y los formatos secretos de

ficheros binarios heredados de Microsoft,que continúan siendo utilizados porMicrosoft Office en su proceso interno.

3. El traductor a ODF "Novell-Microsoft-Clever Age" está diseña-do a medias intencionadamentePor al menos cuatro razones, el conversor deficheros que está desarrollando Clever Age,pagado por Microsoft, e incorporado a laversión de OpenOffice sólo para Novell,nunca será capaz de ofrecer una totalinteroperabilidad entre Microsoft Office ylas aplicaciones que soportan ODF, comoOpenOffice.org.

Las razones tienen que ver con característicasfundamentales tanto del formato EOOXMLcomo del enfoque técnico de Clever Age-Microsoft: XSLT (eXtensible StylesheetLanguage Transformation). Microsoft sabede antemano que XSLT es inadecuado.

Esto no es ninguna sorpresa. Bill Gates nun-ca apuesta sobre nada a menos que tengatodas las cartas. Y mientras la gente pienseque EOOXML es solamente XML y quecualquier XML puede ser transformado fácily universalmente con XSLT, Gates tieneasegurados sus tres ases (95% del mercadode las aplicaciones de escritorio, conversiónperfecta y fiel de los BoBs, y un EOOXMLvinculado tanto a la API heredada deWindows como a los elementos internos dela API de Vista-.NET 3.0).

3.1. Otros desarrolladores no puedenimplementar adecuadamente todoEOOXMLJunto al problema de la dependencia deEOOXML respecto a oscuras instruccionesRTF (Rich Text Format), hay un montón deetiquetas en la especificación EOOXML queno pueden ser implementadas adecuada-mente por nadie más que Microsoft. Aquí semuestran sólo unos pocos ejemplos recogi-dos por Ben Langhinrichs (ver <http://www.geniisoft.com/showcase.nsf/archive/20061027-0829>): autoSpaceLikeWord95autoSpaceLikeWord95autoSpaceLikeWord95autoSpaceLikeWord95autoSpaceLikeWord95 (Emulate Word

95 Full Width Character Spacing) - pp. 1378-1379.

footnoteLayoutLikeWW8footnoteLayoutLikeWW8footnoteLayoutLikeWW8footnoteLayoutLikeWW8footnoteLayoutLikeWW8 (EmulateWord 6.x/95/97 Footnote Placement) - pp.1416-1417.

lineWrapLikeWord6lineWrapLikeWord6lineWrapLikeWord6lineWrapLikeWord6lineWrapLikeWord6 (Emulate Word 6.0Line Wrapping for East Asian Text) - pp.1426-1427.

mwSmallCapsmwSmallCapsmwSmallCapsmwSmallCapsmwSmallCaps (Emulate Word 5.x forMacintosh Small Caps Formatting) - pp.1427-1429.

shapeLayoutLikeWW8shapeLayoutLikeWW8shapeLayoutLikeWW8shapeLayoutLikeWW8shapeLayoutLikeWW8 (Emulate Word97 Text Wrapping Around Floating Objects)- pp. 1442-1443.

suppressTopSpacingWPsuppressTopSpacingWPsuppressTopSpacingWPsuppressTopSpacingWPsuppressTopSpacingWP (EmulateWordPerfect 5.x Line Spacing) - pp. 1462-1464.

truncateFontHeightsLikeWP6truncateFontHeightsLikeWP6truncateFontHeightsLikeWP6truncateFontHeightsLikeWP6truncateFontHeightsLikeWP6 (EmulateWordPerfect 6.x Font Height Calculation) -pp. 1467-1468.

useWord2002TableStyleRulesuseWord2002TableStyleRulesuseWord2002TableStyleRulesuseWord2002TableStyleRulesuseWord2002TableStyleRules (EmulateWord 2002 Table Style Rules) - pp. 1481-1482.

useWord97LineBreakRulesuseWord97LineBreakRulesuseWord97LineBreakRulesuseWord97LineBreakRulesuseWord97LineBreakRules (EmulateWord 97 East Asian Line Breaking) - pp.1482-1483.

wpJustificationwpJustificationwpJustificationwpJustificationwpJustification (Emulate WordPerfect6.x Paragraph Justification) - pp. 1483-1485.

Se trata de características lamentables deversiones anteriores de Microsoft Office quese han mantenido en esta nueva ediciónsolamente con el propósito de compatibili-dad con anteriores versiones. Casi todasestas etiquetas de la especificación EOOXMLestán acompañadas por unos pocos ‘conse-jos’ repetidos que solamente un cínico po-dría ver con algún sentido de hilaridad o que,de hecho, provocan risas convulsivas en losconocedores de los formatos de ficheros:"Para reproducir fielmente este comporta-miento, las aplicaciones deben imitar el com-portamiento de esa aplicación, que implicamuchos posibles comportamientos y no pue-de ser fielmente ubicado en la narrativa deeste estándar Open Office XML. Si las apli-caciones desean replicar ese comportamien-to deben utilizar y duplicar la salida de di-chas aplicaciones."

La especificación y el formato de ficherosEOOXML incuestionablemente contienencientos de instrucciones de proceso que ensu conjunto sólo pueden ser procesadas ade-cuadamente por Microsoft Office. Es unformato de ficheros propiedad de un solosuministrador, un formato de ficheros quetrata el software como un punto de llegadaen vez de como un enrutador de informacióna un conjunto de software de procesos denegocio que no sea el propio y estrechamen-te integrado de Microsoft.

Las citadas etiquetas específicas de aplica-ción podrían ser también burbujas binariasen lo que se refiere a aplicaciones ajenas aMicrosoft. La funcionalidad de las etiquetasestá escondida en la capa de aplicación noespecificada de Microsoft Office en vez deestar especificada en el estándar EOOXMLadoptado por ECMA. La existencia de esasetiquetas desmiente cualquier pretensión deMicrosoft de que EOOXML se ha diseñadopara la interoperabilidad, una pretensiónque aparece en el borrador final de la especi-ficación ECMA, Parte 1: "El objetivo es per-mitir la implementación de formatos OpenOffice XML para el más amplio conjunto deherramientas y plataformas, fomentando lainteroperabilidad entre las aplicacionesofimáticas y los sistemas para líneas de nego-cio, así como dar soporte y fortalecer el archivoy la preservación de los documentos, todo deuna forma que sea totalmente compatible con

novática nº 184 noviembre-diciembre 2006 31

Formato de Documento Abierto (ODF) monografía

monografía

las grandes inversiones existentes en documen-tos Microsoft Office." (Subrayado añadidopor los autores).

Cierra los ojos otra vez. Se ignora el hecho deque ni las especificaciones para los formatosbinarios heredados ni las APIs usadas paralas conversiones se pueden localizar en laespecificación EOOXML; siguen siendo unsecreto muy bien guardado de Microsoft.Toda esta ‘compatibilidad’ con los formatosbinarios se reserva para uso exclusivo de losproductos de un único proveedor, Microsoft.

Puede empezarse a ver con qué claridadfunciona el modus operandi. Mediante unaoscuridad sistemática y una prestidigitaciónaudaz, Microsoft conseguirá que la ISO legarantice un monopolio exclusivo de la mi-gración de ficheros Microsoft Office hereda-dos a XML. ¿A qué ‘sabor’ de XML? Estáclaro, al de Microsoft. No importa queMicrosoft rehusase participar en el desarro-llo del estándar internacional de OpenDocument XML que la ISO ha adoptado ya.No importa que Microsoft rechazase sumi-nistrar soporte nativo para OpenDocumenten Microsoft Office. No importa que desdefebrero de 2003, ODF haya sido capaz detraducir perfectamente todos y cada uno delos BoBs, incluidas las instrucciones de pro-ceso para aplicaciones específicas y las bur-bujas binarias.

Cierra los ojos y retrocederás a 1995: elsoftware como punto de llegada.

Obviamente, si uno sigue la lógica empleadapor Microsoft y ECMA, los consumidoresde software necesitarán todavía una tercerao quizás una cuarta implementación de for-mato de ficheros XML para documentos deoficina. Uno para traducir los ficheros deWord Perfect a XML, e incluso otro máspara el Lotus Notes de IBM. Así pues ¿enqué medida supone la nueva era de formatosXML cualquier tipo de mejora substancialsobre la cacofonía de formatos binarios quehan bloqueado toda interoperabilidad du-rante todas estas décadas?

La inclusión de cientos de etiquetas especí-ficas de proveedor no es la única debilidad deEOOXML, por supuesto. Sólo tres ejemplosmás: la especificación EOOXML tambiénsufre de una dependencia inapropiada res-pecto a las máscaras de bit del sistema ope-rativo Windows, a los parches para los fallosespecíficos de las aplicaciones de Microsofty un parser ad-hoc XML propietario deMicrosoft2 .

No hay que maravillarse en absoluto de queMicrosoft considerase necesario pagar aNovell una gran cantidad de dinero parallevar a cabo una implementación parcial deEOOXML en OpenOffice.org.

3.2. EOOXML es un formato de provee-dor cerradoLa enorme complejidad de la especificaciónEOOXML, alrededor de 6.000 páginas, ade-más de su dependencia de etiquetas específicasde aplicación, de las máscaras de bit deWindows y de los parches para los fallosespecíficos de Office, se traduce en un formatode proveedor cerrado. Esto significa que nadieexcepto Microsoft será capaz de dar un soporteni medianamente completo a la especificación.Esto tiene obvias consecuencias, tal y comoexplica Bob Sutor, de IBM3 : "La total y co-rrecta implementación [de EOOXML] re-querirá la clonación de una gran parte delproducto Microsoft. Y eso en el mejor de loscasos, pues llevan una década de adelanto.También, dado que han evitado usarestándares de la industria como SVG yMathML, tendrás que reimplementar mu-chas cosas al modo Microsoft. Mejor empie-za ahora. Por tanto, concluyo que mientrasMicrosoft puede terminar dando soporte ala mayor parte [de EOOXML] (y tendremosque esperar al producto final para ver cuántoy cómo), otros productos probablementeterminarán dando soporte sólo a unsubconjunto [de EOOXML].

Esto significa que otros productos y otrosoftware NO serán capaces, en la práctica,de entender cualquier [EOOXML] que se leslance. Es intolerable. Por tanto crearán sola-mente el poco de lo que necesitan y lo distri-buirán. ¿Lo distribuirán a quién? Al únicosoftware que lo entenderá: Microsoft Office.Así es cómo veo que evolucionarán las co-sas: [EOOXML] será casi totalmente legibley escribible por los productos Microsoft,pero escribible sólo parcialmente por otrosproductos. Esto significa que los datos enforma [EOOXML] serán absorbidos am-pliamente por el ecosistema Microsoft peroque poco escapará para su uso total y prác-tico en otros ámbitos".

(Ver también el artículo de Sutor citado en lanota 3, que incluye gráficos que representanlos conceptos anteriores, discutidos en tér-minos más generales, y explora la diferenciaen significado entre "interoperabilidad" e"intraoperabilidad").

Sólo en teoría resulta precisa la afirmación deMicrosoft de que el formato de ficherosEOOXML puede ser implementado por cual-quiera. En la práctica, no será posible laimplementación total por parte de otrosdesarrolladores. A menos que, quizás, Novellse comprometa a realizar una ingeniería inver-sa de todas aquellas funciones de versionesprevias de Office invocadas por esos cientos deetiquetas, máscaras de bit de Windows y par-ches para errores de Microsoft Office.

3.3. Novell y Microsoft no tienen inten-ción de conseguir la interoperabilidad

Es especialmente relevante, a la luz de lacomplejidad gratuita de la especificaciónEOOXML, lo que dice Steve Ballmer acercadel conversor de ficheros de EOOXML aODF desarrollado conjuntamente por Novelly Microsoft: "Ni el equipo de colaboraciónintentará construir conversores de ficherosque puedan hacer ficheros cien por ciencompatibles entre dos formatos de ficheros.Pero conseguirá el nivel de interoperabilidadque los clientes necesitan para trabajar."

El director del equipo de desarrollo deOpenOffice.org de Novell, Michael Meeks,está de acuerdo: "Lo que Ballmer dice esverdad en un sentido; cierto, es probable quela interoperabilidad al 100% entre dos apli-caciones no triviales cualesquiera nunca seráposible. Por supuesto eso es engañoso ysiempre que la interoperabilidad sea lo sufi-cientemente buena es improbable que la genteeche de menos ese último 2% (o lo que sea).Para alguna gente, el beneficio que se obtie-ne de añadir el siguiente 1% es tan bajo quea la gente no le preocupa :-) ".

Sin embargo, por lo menos un desarrolladorque ha estado realmente luchando a brazopartido con la conversión de formatos de fiche-ros binarios de Microsoft a OpenDocumentestá en desacuerdo. Gary Edwards, de la fun-dación OpenDocument, que representa tam-bién a la comunidad OpenOffice.org en elComité Técnico de OpenDocument de OASIS(Organization for the Advancement ofStructured Information Standards), dice queel "lo que sea" del Sr. Meeks es substancialmentemayor que el 1 ó 2 por ciento cuando se migranficheros binarios de Microsoft aOpenDocument usando EOOXML como for-mato intermedio: "Los conversores a ODF alos que Ballmer y Novell hacen referencia sonrealmente los mismos filtros de traducciónCleverAge/Microsoft a ODF basados en XSLTcon rutinas suplementarias en C# — rutinasque prueban sin ninguna duda que EOOXMLno está preparado para XSLT. El convertidorCleverAge será la parte central del pluguin queestá siendo desarrollado para el OpenOffice deNovell. Ballmer está en lo cierto al decir quenadie conseguirá en ninguna parte, haciendouso de métodos XSLT, el 100% de fidelidadque define a la ‘interoperabilidad’".

La razón por la que XSLT nunca funcionará enesta situación es porque XSLT necesita unXML "Xpath-perfect" altamente estructuradopara una transformación perfecta. ODF fueescrito para ser la estructura XML "Xpath-perfect" que le hace falta a XSLT. Sin embar-go, EOOXML es todo menos perfecto.

Las deficiencias estructurales de EOOXMLque hacen que XSLT sea casi inútil (digamosque consigue un 60% de fidelidad máxima,comparado con la fidelidad, tampoco suficien-te, de un 85% que se obtiene con los filtros

novática nº 184 noviembre-diciembre 200632

monografía Formato de Documento Abierto (ODF)

monografía

tradicionales de ingeniería inversa deOpenOffice.org y que ha sido considerada unahazaña extraordinaria por todo aquel que al-guna vez ha intentado hacer este trabajo) estáncentradas en el modelo de ‘estilos’ (presenta-ción) con una estructura desajustada que tieneEOOXML.

Y esta estructura desajustada y demediada estáa su vez directamente relacionada con el senci-llo motor de representación (layout) deMSOffice. (Sencillo en comparación con elrico y complejo motor de representación deOpenOffice).

La declaración de Ballmer de que ni Novellni Microsoft ni CleverAge intentarán alcan-zar el 100% de fidelidad significa en efectoque seguirán usando XSLT como método detransformación".

Además, cuando tratamos el software comoun enrutador de información en un procesode negocio, donde la misma informacióndebe ser leída y escrita por un conjunto dediversas aplicaciones, solamente es válida latotal interoperabilidad. Un proceso de nego-cio que permite la pérdida de datos en cadatrayecto de una aplicación a otra no es‘interoperabilidad’. Decir "el nivel deinteroperabilidad que los clientes necesitanpara trabajar" tiene tan poco sentido comodecir "parcialmente embarazada".

De hecho, el mismo libro blanco deEOOXML de ECMA dice en la sección 4.6que cuando se migren ficheros heredados enformato binario Microsoft a XML solamen-te funcionarán plenamente traducciones de"alta fidelidad":

"Migración de alta fidelidad: "Migración de alta fidelidad: "Migración de alta fidelidad: "Migración de alta fidelidad: "Migración de alta fidelidad: OpenXML estádiseñado para dar soporte a todas las carac-terísticas de los formatos binarios deMicrosoft Office 97-2007. Es difícil exagerarla dificultad de lograr este objetivo y la con-siguiente posición única de OpenXML paraconseguirlo ... Se pretende que OpenXMLpermita la futura edición o manipulación almismo nivel de abstracción que tenga elcreador original".

Pero solamente si Microsoft Office es laherramienta de edición. Ver también la sec-ción 4.7 del mismo documento ("Integrationwith business data").

3.4. El proyecto conjunto no satisfarálos requerimientos del mercadoA pesar de la pretensión de Novell y Mr.Balmer de que esa migración "suficiente-mente buena" de formatos Microsoft a ODFes suficiente, en todo el mundo las leyesdemandan claramente un 100% de fidelidaden las migraciones de documentos binarios aXML. Ver, por ejemplo, la sección 7001 deley norteamericana de firma electrónica, se-

gún la cual los registros conservadoselectrónicamente "deben reflejar conprecision [] la información contenida en elcontrato o en cualquier otro registro" y estar"en un formato capaz de ser reproducido conprecisión para su posterior consulta, pormedio de transmisión, impresión o de cual-quier otro método"; o la sección 7261 de laley Sarbanes-Oxley (la información finan-ciera no debe "contener una versión falsa deun hecho material").

La mediocre migración "suficientementebuena" a ODF de registros heredados con-templada en el acuerdo Novell-Microsoft noes ni de lejos suficientemente buena en esteentorno legal. Un único usuario puede sercapaz de convertir un único fichero y luegocomprobar manualmente que no se ha per-dido ninguna información. La situación estotalmente diferente cuando los documen-tos deben ser convertidos sucesivamente oen caso de conversión masiva o completa-mente automatizada de ficheros.

4. Se pueden satisfacer los reque-rimientos del mercado en cuantoa interoperabilidadMiguel de Icaza, de Novell, eludió contestara la siguiente pregunta importante que lehizo Pamela Jones: "Díganos también porfavor, en qué fallan desde su punto de vista,las soluciones de Sun o de la FundaciónODF y si puede explicarnos cuáles son lasdiferencias entre lo que harán ustedes y ellos".

Icaza respondió: "Michael [Meeks], directorde nuestro equipo de OpenOffice, que ca-sualmente está visitando la ciudad, dice: ‘Lasolución de la fundación ODF no es soft-ware libre; la de Sun no está publicada’".

Contrariamente a la afirmación del Sr.Meeks, la OpenDocument Foundation to-davía no ha tomado una decisión final sobrela licencia de los productos de conversión deficheros que está desarrollando pero se estáinclinando decididamente hacia distribuir-los bajo la licencia de software libre y abiertoGPL, y ha entablado un diálogo con loslíderes de la comunidad ODF.

En lo que respecta a las diferencias entre lassoluciones, la solución de Sun es un envolto-rio C# sobre OpenOffice.org que usa lastradicionales facilidades de importación-ex-portación de OOo. Según Edwards, es posi-ble alcanzar una fidelidad de alrededor del85% en la traducción entre binarios Microsofty OpenDocument. La base de este método esel mismo proceso de filtrado que ahora usaOpenOffice 2.0. No se puede obtener una‘mejora’ por ningún lado. El grupo Microsoft/Clever Age está trabajando en filtros XSLT-C# que traducen entre EOOXML yOpenDocument. Debido a los desafíos es-tructurales que presenta cualquier método

basado en XSLT, CleverAge debería obtenerel premio tecnológico de la década si pudieraalcanzar un máximo de un 60% de fidelidad.Las herramientas de la ODF sin embargoestán diseñadas para alcanzar una alta fide-lidad superando las trampas de EOOXML,trabajando directamente con los formatosde conversión RTF modificados de MicrosoftOffice. Una de las herramientas de la funda-ción es el plugin ODF para Microsoft Office,un plugin apodado "da Vinci" que usa lasmismas APIs internas de Office utilizadaspor Microsoft para los formatos que soportade forma nativa. La otra es una API autónomaXML Infoset de ODF que puede ser usada enaplicaciones (también en el lado del servidor)que soporten ODF para importar y exportarformatos binarios de Microsoft. Una tercera,es un plugin da Vinci para OpenOffice.org. Yuna cuarta es un "asistente de interoperabilidad"diseñado para garantizar que las estaciones detrabajo OpenOffice integradas en el proceso denegocio y flujo de trabajo de MSOffice produz-can documentos perfectamente interoperables.

Edwards dijo que el plugin da Vinci y la APIOpenDocument Infoset podrán alcanzar el100% de fidelidad al traducir entre binarioscon formato de Microsoft y ODF para apli-caciones que implementen correctamente laespecificación de formato OASISOpenDocument versión 1.2.

La versión 1.1 de la especificación ODF secentra en las tecnologías de ayuda y ha sidorecientemente aceptada por el Comité Téc-nico OpenDocument de OASIS. La versiónODF 1.2 es la equivalente de "interopera-bilidad con esteroides" y recibirá toda laatención del comité en enero y febrero de2007. Edwards aconseja a los usuarios deMicrosoft Office 2007 que cambien las op-ciones por defecto del paquete y guarden sustrabajos en los formatos tradicionales enlugar de en EOOXML con objeto de facilitarla migración a ODF después de que lasherramientas de la Fundación estén disponi-bles.

Pero dice que hay razones más importantespara evitar el uso de EOOXML: "Una vezque los procesos de negocio vinculados aMicrosoft Office se transfieran a EOOXML,esos procesos estarán listos para la migra-ción hacia la cadena de proceso de informa-ción basada en Microsoft Exchange/Sharepoint Hub. Las organizaciones quecaigan en la trampa de esa "migración deprocesos de negocio" no podrán dejar enmucho tiempo la cadena de procesos deMicrosoft. Podrían también tener que firmarun contrato de arrendamiento con Microsoftdurante al menos los próximos quince años.Deberían asegurarse de que el acuerdo cubreel gasto de las ocho aplicaciones de escrito-rio y nueve sistemas del lado del servidornecesarios para expandir y mejorar esos pro-

novática nº 184 noviembre-diciembre 2006 33

Formato de Documento Abierto (ODF) monografía

monografía

cesos de negocio altamente productivos, peroencadenados a EOOXML".

Las herramientas de la Fundación son lasúnicas de entre las que hasta ahora se hanpresentado al público que prometen totalinteroperabilidad entre Microsoft Office (ysus formatos binarios) y las aplicaciones quesoportan ODF. Los desarrolladores de laFundación empezaron con la última docu-mentación pública de las APIs de conversiónde ficheros de Microsoft Office antes de queMicrosoft decidiera que todas las futurasmejoras serían secretas y así lograron dedu-cir cuál es la naturaleza de las etiquetassecretas. Nuestro plugin da Vinci añade so-porte nativo para ODF a Microsoft Office,algo que ninguna de las otras herramientasvenideras ofrecerá. Microsoft Office puedede esta forma ser usado en proceso por lotescomo una "bomba" que permita migrar conuna incomparable fidelidad documentos enformatos heredados de fichero de Microsofta formato OpenDocument.

El principal punto de la estrategia de laFundación es el siguiente: impulsar la crea-ción de cadenas alternativas de proceso deinformación ODF que puedan competir conlas cadenas dominadas por EOOXML. Losprocesos de negocio vinculados a MSOfficevan a migrar a hubs estilo E/S altamenteproductivos. Nada va a parar o alterar estamigración. La única cuestión es ¿estaránpreparados esos hubs para EOOXML o paraODF? Así pues no tiene sentido interrumpirlos actuales flujos de trabajo y servicios parareescribir esos procesos a alternativas deescritorio listas para ODF.

Lo que tiene sentido es, en primer lugar,meter esos procesos de negocio vinculados aMSOffice en ODF. Meter esos documentosy flujos de documentos y datos en ODF. Paraeso está da Vinci. En segundo, migrar esosprocesos de negocio vinculados a MSOfficea hubs preparados para ODF. Éste es elprincipal propósito de nuestro ODF InfosetEngine - API; un servidor ligero y un motoren el lado del dispositivo que puede automa-tizar aplicaciones ODF.

La total fidelidad de esas migraciones sólopuede ser factible debido a que ODF fuediseñado de manera intencionada para faci-litar la interoperabilidad e incluye caracte-rísticas diseñadas específicamente parainteroperar con Microsoft Office. ODFimplementa un sistema en el cual los elemen-tos y atributos no reconocidos o extrañosson preservados por una aplicación que cum-ple los requisitos. Ver OpenDocumentspecification, sección 1.5., disponible en<http://develop.opendocumentfellowship.org/spec/> (pero nótese que donde dice "de-bería" y "puede" en esa sección se espera quediga "debe" en la versión 1.2, y que está

previsto que se refine más todavía lainteroperabilidad en dicha especificación.)

Estos requerimientos (generalmente deno-minados por la comunidad de desarrollo deODF como foreign elements y unknownelements, o simplemente como Microsofttags) ponen en duda la afirmación deMicrosoft de que es necesario un estándarseparado para asegurar la compatibilidadcon esos miles de millones de ficherosbinarios de Microsoft Office heredados.

El plugin da Vinci ha llegado a un nivel dedesarrollo que va mucho más allá de la etapade pruebas y ha sido aceptado por multitudde departamentos de administraciones pú-blicas de todo el mundo, incluyendo unademostración en Europa a la que asistierondirectivos de Microsoft, quiénes justo al díasiguiente anunciaron públicamente su defi-ciente proyecto ODF XSL Transformer, unaacción poco consecuente para una compa-ñía que pretende ser promotora de lainteroperabilidad del software.

5. El acuerdo Novell-Microsoftplantea problemas antimonopolioCuando se anunció el acuerdo Novell-Microsoft, y hasta ahora, ambas empresasproclamaron que los usuarios estaban de-mandando interoperabilidad entre las apli-caciones de Microsoft y ODF. Eso, y lanecesidad de compartir la tecnologíavirtualizada de sistema operativo, son lasprincipales justificaciones para el acuerdo,según ambas empresas. Sin embargo es tam-bién incuestionable que las dos empresas sedieron cuenta de que su acuerdo no propor-cionaría lo que el mercado requiere en cuan-to a interoperabilidad.

En lugar de eso, el acuerdo consolida la nointeroperabilidad durante cinco años más,reduciendo en la práctica el nivel de fidelidadque se puede conseguir hoy con los filtros deimportación-exportación de OpenOffice.orgal desviar a los usuarios desde conversionesde formatos binarios hacia herramientas XSLTransformation que son aún menos fiables.

Cualquier discusión honesta sobre el acuer-do Novell-Microsoft debe comenzar pre-guntando a ambas compañías: [i] por qué seniegan a proporcionar lo que el mercadopide; y [ii] por qué han sellado esa negativaconjunta mediante un contrato vinculante.Ambas empresas aparentemente son cons-cientes de que es posible una interopera-bilidad total. Pero el acuerdo Novell-Microsofthasta ahora parece menos un "acuerdo para lainteroperabilidad" y bastante más un acuerdoprohibido de eliminación de la competencia yasignación ilegal del mercado de software deproductividad de oficina, una forma de restric-ción del comercio contemplada por la LeySherman4 de los EE.UU.

Según ese acuerdo, Novell se queda con lacuota de mercado de la producción de softwarede productividad de oficina basado enOpenDocument y Microsoft se queda con lacuota del mercado correspondiente al softwarebasado en EOOXML. La aparente conspira-ción protege de sus competidores la cuota demercado asignada a cada una de las partesmediante una patente espesa e indefinida acep-tada públicamente por ambas compañías enforma de pacto para que ninguna demande alos consumidores de pago de la otra. Estos tanpublicitados pactos de no litigación amenazanimplícitamente con costosos procesos judicia-les por infracción de patente a cualquiera queuse otros productos.

Que Novell sabe que es posible unainteroperabilidad mucho mayor está am-pliamente demostrado por el hecho de quedos días antes de que el acuerdo fuera firma-do y anunciado, fichó al máximo responsa-ble tecnológico de la OpenDocumentFoundation, Florian Reuter, un experto re-conocido mundialmente en la conversión ytratamiento de documentos. Novell sabíaindudablemente, antes de firmar conMicrosoft, en qué estaba trabajando Reuter.Además, Microsoft no ocultaba que podíaproporcionar soporte total para OpenDocument en Microsoft Office.

El anterior Secretario de Administración yFinanzas del Estado de Massachussets, EricKriss explicó que técnicos de Microsoft ledijeron que sería ‘trivial’ añadir soporte ODF alnuevo Office 2007. La resistencia a hacerloproviene del lado de la empresa proveedora.

Así pues resulta que Novell y Microsoft sa-bían que se podía conseguir la interoperabi-lidad total y sabían que ésta era un requeri-miento del mercado, pero conspiraron paraasegurarse de que a los usuarios de softwareno se les diese la total interoperabilidad quedemandaban, haciendo uso intencionada-mente de herramientas inadecuadas de trans-formación XSL a manera de "coartada"antimonopolio en un acuerdo para mante-ner elementos software separados y nointeroperables y no competir en un mercadorepartido entre ambas empresas. Admitenque el conversor Microsoft-Clever Age-Novell EOOXML-to-ODF no alcanzará lainteroperabilidad total y por tanto no es loque mercado requiere. Un acuerdo para noproporcionar lo que pide el mercado con elfin de repartir un mercado entre dos empre-sas es descaradamente anticompetitivo.

Novell todavía podría salvar su maltrechaimagen entre la comunidad de software librey abierto apoyando de manera sólida (ypúblicamente) las soluciones de la OpenDocument Foundation. De este modo, Novellpodría también evitar una predecible ola dedemandas antimonopolio tanto en EE.UU.

novática nº 184 noviembre-diciembre 200634

monografía Formato de Documento Abierto (ODF)

monografía

como en Europa a las que tiene menos pro-babilidades de sobrevivir que Microsoft.

Novell al fin y al cabo tiene unos abundantesy recientes fondos que atraerán a los tiburo-nes. Pero independientemente de lo que haga,Novell debería dejar de vender su acuerdocon Microsoft como un "acuerdo deinteroperabilidad". La verdadera base delacuerdo es embarazosamente transparentey la compañía sólo puede perder más credi-bilidad si continúa con esta farsa.

Debería recordarse que en un proceso denegocio un formato de fichero es en cadauno de sus bits tanto un protocolo de comu-nicaciones como un método de almacenarinformación. La Dirección General de laCompetencia de la Comisión Europea yahabía decidido anteriormente que el rechazode Microsoft a revelar sus protocolos decomunicaciones para Windows y servidoresWindows a sus competidores era una viola-ción de la libre competencia. Pero la esaDirección General no limitó su decisión sóloa los protocolos de Windows; ordenó aMicrosoft abstenerse "de cualquier acto oconducta... con efecto u objeto equivalente",un tema planteado por el Comité Europeopara los Sistemas Interoperables cuando éstepresentó su queja a la Dirección General dela Competencia debido al rechazo deMicrosoft a dar soporte a ODF y a su nega-tiva a desvelar las especificaciones para susformatos de ficheros binarios Office.

Como Novell fue una de las empresas queinstigó y tomó parte en el litigio antimo-nopolio europeo contra Windows, parecealgo más que incongruente para Novell con-vertirse posteriormente en un co-conspira-dor en la apuesta de Microsoft para usar elsecreto de sus formatos de fichero Office ylas APIs de conversión de ficheros, APIs conel fin de frustrar la total interoperabilidadcon el software que da soporte a ODF.

Esto es especialmente cierto en un acuerdoque pretende también compartir tecnologíaspara la virtualización del sistema operativode ambas empresas. ¿Qué hay de bueno en lavirtualización de los sistemas operativos silas aplicaciones de negocio que se ejecutanbajo esos sistemas operativos concurrentesno pueden interoperar? ¿No es éste un "efec-to u objeto equivalente" al de la negativa deMicrosoft de revelar sus protocolos de co-municaciones Windows? De abiertoEOOXML sólo tiene el nombre.

Novell conoce perfectamente bien lo que laley tiene que decir al respecto. De hecho,Microsoft pagó a Novell 536 millones dedólares para que dejase de participar en elcaso antimonopolio de la Comisión Euro-pea. Después de haber abogado con éxitopara que se obtuviese el mandato judicial,

Novell está en una débil posición para opo-nerse a su implementación. El argumento deque "nosotros no nos podíamos permitirrechazar un segundo cheque" no es unadefensa fuerte para un caso de conspiraciónantimonopolio, donde un acusado es res-ponsable no sólo de sus actos, sino tambiénde los actos y omisiones de quienes conspi-raron junto a él.

6. Conclusión: la guerra fría deXML en un cambiante mercado desoftwarePara comprender completamente el bloqueode proveedor y el vínculo legal que Microsofty Novell están ideando, es importante enten-der cómo la adopción de EOOXML de aquía uno o dos años por parte de la ISO/IECproduciría una ampliación legalmente san-cionada del monopolio de Microsoft en losformatos de documentos de oficina. A travésde su acuerdo de tecnología compartida conNovell y su elaborado mensaje sobre la‘interoperabilidad’, Microsoft busca audaz-mente reafirmar sus viejos bloqueos propie-tarios adornando su comportamiento con ellenguaje ‘abierto’ que está hoy de moda.

El problema legal fundamental de la adopciónde EOOXML por la ISO como un estándarinternacional es que haría que su uso fueraobligatorio en muchas situaciones, tanto en elsector privado como en el gubernamental. Porla misma razón, su uso estaría prohibido enmuchas de esas mismas situaciones si no fueraaprobado por la ISO. (Ver el artículo 2 delAcuerdo sobre barreras técnicas al comercio yel artículo VI del Acuerdo sobre compras de lasAdministraciones Públicas — ambos de laOrganización Mundial del Comercio, OMC).Estos tratados pretenden, entre otras cosas,estimular la competencia mediante la promo-ción del desarrollo de estándares abiertos convalor legal, eliminar la multiplicación deestándares donde haya solo uno que sea sufi-ciente y exigir el uso de los estándares aproba-dos. Así pues, la capacidad de desarrolladoresno Microsoft para implementar EOOXML esun asunto crucial para evaluar la adecuaciónde EOOXML como candidato a convertirseen un estándar internacional.

Pero para comprender plenamente la guerradesencadenada en torno a OpenDocument yEOOXML, se debe primero entender que lasreglas básicas del mercado de software deoficina se hallan en un estado de cambiocontinuo. Vivimos en la era de Internet. Laera del acceso e intercambio universal. Laera de la conectividad universal y de la com-putación colaborativa. Las cosas están cam-biando continuamente. En los tiempos queestamos dejando atrás, el software de oficinafue diseñado como un punto de llegada. Elcamino para alcanzar la interoperabilidadsignificaba que cada uno de los usuarios deuna oficina, y quienes intercambiaban fiche-

ros con esa oficina, utilizaran el mismo soft-ware. Los programas de los diferentes pro-veedores usaban formatos de fichero dife-rentes e incompatibles. Intercambios y flujosde información estaban totalmente vincula-dos a una API. Era una situación similar a laTorre de Babel que en último término des-embocaba en que un único proveedor desoftware — Microsoft Office — alcanzase elmonopolio principalmente mediante unacombinación de incompatibilidades de losformatos de ficheros y la venta conjunta desu software con los nuevos ordenadores.

Pero aunque Microsoft alcanzó el dominiodel mercado de los paquetes de oficina, dife-rentes fuerzas estaban trabajando para im-pedir su predominio. Uno de estos factoresera el auge de una red basada en estándaresabiertos como son Internet y las redes ubi-cuas. Otro factor importante era la crecientecrisis de complejidad: "En las últimas cuatrodécadas, las arquitecturas de software hanintentado lidiar con los crecientes niveles decomplejidad del software. Pero el nivel de com-plejidad no para de crecer y las arquitecturastradicionales parecen estar llegando al límitede sus posibilidades de solucionar el problema.Al mismo tiempo, persisten las tradicionalesnecesidades de las organizaciones de TI: lanecesidad de responder de forma rápida a losnuevos requerimientos de negocio, la necesi-dad de reducir continuamente el coste de las TIde la organización, y la capacidad de absorbere integrar nuevos socios de negocio y nuevosgrupos de clientes, por citar algunos. Comoindustria, hemos pasado por muchas arquitec-turas de computación diseñadas para permitirun proceso totalmente distribuido, lenguajesde programación diseñados para ser utilizadosen cualquier plataforma, tiempos de imple-mentación muy reducidos y una miríada deproductos de conectividad diseñados para per-mitir una mejor y más rápida integración de lasaplicaciones. Sin embargo, la solución integralsigue escapándosenos.

Ahora se pueden encontrar entornos máscomplejos. Los sistemas heredados debenser reutilizados en lugar de substituidos,porque con unos presupuestos cada vez másajustados la substitución tiene un coste pro-hibitivo. Vemos que el acceso barato y ubi-cuo a Internet ha creado la posibilidades demodelos de negocio completamente nuevos,que deben por lo menos ser evaluados por-que ya lo está haciendo la competencia. Elcrecimiento por fusión o adquisición se haconvertido en algo habitual, de modo queorganizaciones, aplicaciones e infraestruc-turas de TI deben ser integradas y absorbi-das. En un entorno de semejante compleji-dad, las soluciones puntuales sólo acrecien-tan el problema y nunca nos harán salir delagujero. Deben desarrollarse sistemas en losque la heterogeneidad sea algo fundamentalpara el entorno, porque se deberán permitir

novática nº 184 noviembre-diciembre 2006 35

Formato de Documento Abierto (ODF) monografía

monografía

el ajuste entre una gran variedad de hardware,sistemas operativos, middleware, lenguajesy almacenamiento de datos. El efectoacumulativo de décadas de crecimiento yevolución ha producido una enorme com-plejidad. Con todos esos retos de negociopara las TI, no es de extrañar que la integra-ción de aplicaciones sea una de las primerasprioridades de muchos CIOs" (Ver"Migrating to a service-oriented architecture"de Kishore Channabasavaiah et al., <http://www-128.ibm.com/developerworks/library/ws-migratesoa/>).

Para enfrentarse al desafío planteado poresa crisis de complejidad, empezó a surgiruna nueva Arquitectura Orientada a Servi-cios (SOA). La SOA está en gran parteconstruida en torno a XML, un lenguajeextensible de marcado abierto y legible, usa-do como bloque fundamental para futurasexpansiones. Al igual que ocurre con losdatos almacenados en importantes formatosde fichero heredados, la SOA requiere infini-tas repeticiones del siguiente flujo de traba-jo: [i] identificar la posición y forma de losdatos especificados por la aplicación solici-tante; [ii] convertir los datos desde formatosde fichero heredados a un formato XMLválido; [iii] extraer de forma programadaaquellas porciones de datos que han de serreadaptadas; [iv] introducir los datos en unproceso de transformación XML; [v] extraerlos datos en el formato XML requerido; y[vi] serializar esos datos a la aplicación es-pecificada en el flujo de trabajo para suposterior proceso.

Obsérvese que en ese supersimplificado flujode trabajo las aplicaciones son puntos de paso,es decir enrutadores de información más quepuntos de llegada. Aplicaciones diseñadas enlos días de la "red pedestre" (N. del T.N. del T.N. del T.N. del T.N. del T.: sneakernet o red construida mediante el intercambiomanual de soportes digitales), como es el casode Microsoft Office, tienen pronunciadas des-ventajas. La migración sin fallos de datos entreformatos es un elemento integral de un procesoSOA. Los flujos de trabajo que incorporanestos pasos son conocidos comúnmente comoprocesos de negocio.

Microsoft es capaz de predecir las tenden-cias de la industria tan bien como cualquierotro proveedor. Por ello no es sorprendenteque Microsoft esté desarrollando su propiopaquete de software propietario de procesosde negocio. Ese paquete, la infame cadenade proceso de la información, usa EOOXMLno sólo como un formato de fichero, sinotambién como un protocolo de comunica-ciones entre las diversas aplicaciones. Por lotanto, EOOXML es bastante más que sola-mente un formato de fichero para un paque-te de aplicaciones de oficina. Al igual queOpenDocument, está siendo diseñado comouna herramienta de interoperabilidad para

procesos de negocio dentro de solucionestales como SOA. Como se verá a continua-ción, la diferencia es que EOOXML es unaespecificación cerrada y propietaria. Por elcontrario, ODF es completamente abierta.

Tampoco es una casualidad que la guerraentre los partidarios de OpenDocument XMLy el XML de Microsoft Office 2003 (un antece-sor de EOOXML) apareciese primero ante elpúblico durante el diseño de la SOA tanto através del Informe Valoris de la Unión Europeacomo del Estado de Massachusetts con suModelo de Referencia Técnico para Empresasde la División de Tecnologías de la Informa-ción (ITD). El proceso de diseño de esa arqui-tectura creó la necesidad de elegir qué formatode fichero XML sería el formato de destinopara los formatos de ficheros binarios hereda-dos de Microsoft. Por diversas razones. LaITD de Massachusetts eligió OpenDocumentcomo ese formato de fichero. Naturalmente laSOA es sólo una parte de la historia. Uncreciente número de webs y de aplicacionesdistribuidas de web da soporte a OpenDocument, incluyendo el modelo SaaS (Soft-ware as a Service) y la nueva generación de laWeb, la Web 2.0.

Aquí nos encontramos. Es hora de tomar unadecisión. Microsoft está ofreciendo una cade-na de proceso de la información basada enEOOXML muy convincente y con muchoselementos que supone un gran impulso para labase monopolista ya instalada de aplicacionesMicrosoft Office, procesos de negocio vincula-dos y BoBs cerrados heredados. Se trata sinduda de un objetivo de negocio diseñado exac-tamente para extender el monopolio desde losordenadores de escritorio a los servidores, dis-positivos y demás. Asusta, por decirlo suave-mente. No nos extraña en absoluto. Increíble-mente audaz.

Por otra parte, ODF está diseñado y destinadoa ser un formato universal de ficheros indepen-diente de aplicaciones, plataformas, necesida-des de archivo y avances en las TI aún desco-nocidos. Es un formato universal de ficheros alservicio de las necesidades de dominios deinformación tan diversos, y que sin embargotodavía están solicitando una conectividad yun intercambio interoperables, como son losentornos productivos de ordenadores de so-bremesa, la publicación empresarial, los sis-temas de gestión contenidos y de archivos,SaaSs, SOA, la Web 2.0 y más.

EOOXML incumple decididamente lo queXML promete: la fácil transformación uni-versal y la interoperabilidad interge-neracional. Pero no tema, la perfectainteroperabilidad entre ODF y los miles demillones de documentos binarios está yadisponible en ODF 1.2. Y luego está el pro-metedor potencial de la cadena de procesode información ODF del plugin de la Funda-

ción Da Vinci (su plugin de ODF paraMicrosoft Office) y su API ODF InfoSet.

ODF está listo. Le lleva dos años de adelantoa EOOXML en el proceso de estandarizaciónde ISO. ¡Que comience la batalla!

AgradecimientosMarbux, un abogado retirado, miembro volunta-rio de la OpenDocument Fellowship, contribuyórealizando un análisis legal del artículo.

Referencias

1 La interoperabilidad conlleva normalmente un sen-tido de ausencia total de barreras. Ver, por ejemplo, ladefinición que da ISO/IEC 2382-01, tal como se citaen la versión inglesa de Wikipedia ("La capacidad decomunicar, ejecutar programas o transferir datosentre varias unidades funcionales, de forma que serequiera poco o nulo conocimiento por parte delusuario sobre las características específicas de es-tas unidades").2 Para una crítica más detallada de EOOXML dentro delcontexto de una SOA, ver el artículo "IBM’s potentialMS-Office killer to roll out by year’s end" de GaryEdwards, disponible en <http://talkback. zdnet.com/5208-10532-0.html?forumID=1&threadID=13561&messageID=273162&start=-4>.3 "Is Open XML a one way specification for mostpeople?", disponible en <http://sutor.com/newsite/blog-open/?p=1145>. Rob Weir, de IBM, ha publi-cado después una replica satírica al artículo de Sutor(ver "How to Write a Standard (If you Must)", en<http://www.robweir.com/blog/2006/12/how-to-write-standard-if-you-must.html>).4 Caso Palmer contra BRG de Georgia, Inc., 498 U.S.46, 50 (1990): "tales acuerdos van contra la librecompetencia independientemente de si las partesdividen un mercado dentro del cual ambas hacennegocio o de si se limitan a reservar un mercado parauna y otro para la otra". Ver también la Sección 1 delCódigo de Comercio de los EE.UU. en <http://caselaw.lp.findlaw.com/casecode/uscodes/15/chapters/1/sections/section_1. html>: "Se declarailegal todo contrato, o acuerdo en forma de compro-miso o en cualquier otra forma, o conspiración quesuponga una restricción del intercambio o comercioentre varios Estados o con naciones extranjeras.Quien firme un contrato o participen en cualquieracuerdo o conspiración que este código declareilegal será considerado culpable de delito y si escondenado será castigado con una multa no superiora 10.000.000$, si el implicado es una persona jurídi-ca, y si es otro tipo de persona, de 350.000$ o conpena de prisión no superior a tres años o con ambaspenas, según estime el tribunal". Los tribunales hanimpuesto la condición de que la restricción del comer-cio debe ser "no razonable". En aplicación de la LeySherman, para decidir si una restricción del comerciono es razonable hay que "basarse (1) en la naturalezao carácter del contrato o (2) en circunstancias queden lugar a la inferencia o presunción de que sepretende restringir el comercio o elevar los precios",según la sentencia del Tribunal Supremo de losEE.UU. en el caso NCAA contra. Board of Regents ofUniv. of Okla., 468 U.S. 85, 103 (1984), citando elcaso National Society of Professional Engineers con-tra United States, 435 U.S. 679, 692 (1978); lasentencia está disponible en <http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=US&vol=468&invol=85>.

novática nº 184 noviembre-diciembre 200636

monografía Formato de Documento Abierto (ODF)

monografía

1. Políticas gubernamentales deadopción de ODFEl modo de adopción de ODF entre la miríadade autoridades públicas que han anunciadosu soporte a ODF no ha sido uniforme.Hasta la fecha, estas acciones políticas hantomado forma de leyes, decisiones ejecuti-vas, marcos de interoperabilidad, o declara-ciones políticas. Los primeros en adoptarlose encuentran en distintos estadios de suimplementación. Algunos gobiernos hanhecho declaraciones políticas, mientras otrosestán en el proceso de transición de susagencias gubernamentales a ODF en cuantoa su interacción electrónica entre ellas y conel público en general.

Gartner, un suministrador de servicios deconsultoría y análisis de las Tecnologías dela Información (TI), cree que hay un 70% deprobabilidad de que para el 2010 el inter-cambio de documentos ODF sea un requeri-miento del 50% de los gobiernos y del 20% delas organizaciones comerciales1 .

1.1. Gobiernos nacionalesBélgicaBélgicaBélgicaBélgicaBélgica: : : : : el 23 de junio de 2006, el Consejo deMinistros belga adoptó una recomendaciónque efectivamente introduciría ODF como elestándar preferente dentro de sus agenciasgubernamentales para la creación e inter-cambio de texto, hojas de cálculo y presenta-ciones2 . Sus directrices exponen que todoslos documentos intercambiados en el ámbi-to del gobierno federal deben estar en forma-to abierto y estándar, basados en XML eimplementados por más de un proveedor. ElConsejo está recomendando una aproxima-ción en fases en la que la funcionalidad delectura sería implementada en las adminis-traciones públicas belgas antes del 1 de sep-tiembre de 2007, la funcionalidad de escritu-ra antes del 1 de septiembre de 2008, y elintercambio de documentos en ODF antesdel 1 de octubre del 2008.

Croacia: Croacia: Croacia: Croacia: Croacia: como parte del Plan Operacionalpara la implementación de "e-Croacia 2007-Programa para el 2006", se recomienda quelas entidades gubernamentales a todos losniveles generen y archiven su contenido digitalhaciendo uso de formatos abiertos comoparte del plan eCroacia3 .

Dinamarca: Dinamarca: Dinamarca: Dinamarca: Dinamarca: el Parlamento danés decidiópor unanimidad el 2 de junio de 2006 que,para enero del 2008, toda la información

digital intercambiada entre autoridades yciudadanos, empresas e instituciones, debe-ría estar disponible en formatos basados enestándares abiertos4 . Además, todo el desa-rrollo y compra de software para uso delsector público debería estar basado enestándares abiertos como muy tarde para el1 de enero del 2008. La hoja de ruta paraimplementar la decisión esperaba ser consi-derada como muy tarde a finales de 2006.

Francia: Francia: Francia: Francia: Francia: la Dirección General de la Moderni-zación del Estado (DGME) se refiereespecíficamente a ODF en su borradorRéférentiel Général d’Interopérabilité (RGI,Referencia General de Interoperabilidad). Bajoel RGI, seguido en general por todas lasadministraciones públicas francesas, se requiereser capaz de aceptar todos los documentosgenerados en ODF, se recomienda usar ODFen sus aplicaciones de oficina (texto, diagramas,presentaciones), y se prohíbe migrar a formatosque en la actualidad sean utilizados por unaúnica organización5 .

Malasia:Malasia:Malasia:Malasia:Malasia: la organización de estándaresmalasia votó por proponer ODF como unestándar de facto en su país. En mayo del2006 la ISO reconoce ODF como un estándarinternacional6 . Después de un periodo pú-blico de comentarios en septiembre, el Mi-nisterio de Ciencia, Tecnología e Innova-ción malasio está a la espera de formalizar laaprobación de ODF para finales de año,recomendando el formato para su uso en elsector público.

Noruega:Noruega:Noruega:Noruega:Noruega: la política del documento eNorway2009- the Digital Leap (El Salto Digital de

eNoruega 2009) establece que para el año2009 todas las tecnologías y sistemas deinformación se basarán en estándares abier-tos, y que durante el 2006 tendrían queestablecerse un grupo de estándares admi-nistrativos para el intercambio de informa-ción7 . El Ministerio de Administración yReforma Gubernamental ha creado un gru-po de expertos para establecer estándarespara la información electrónica en el sectorpúblico.

1.2. Regiones, estados y municipiosExtremadura (España):Extremadura (España):Extremadura (España):Extremadura (España):Extremadura (España): el Gobierno aprobóuna moción por la que antes del 25 de juliodel 2007 todas las administraciones debenhacer uso del estándar ODF para el inter-cambio de documentos y del formato PDF/A "cuando se requiere garantizar la visuali-zación inalterable de un documento"8 .Extremadura decidió en el año 2002 migrar70.000 ordenadores de sobremesa a unaversión de sistema operativo libre, de códigoabierto basada en Debian, conocida comognuLinEx.

Massachusetts (EE. UU.):Massachusetts (EE. UU.):Massachusetts (EE. UU.):Massachusetts (EE. UU.):Massachusetts (EE. UU.): el "Modelo deReferencia Técnico de las Empresas de laMancomunidad de Massachusetts" de sep-tiembre del 2005 estableció que ODF debíaser usado para documentos textuales, hojasde cálculo y presentaciones9 . Planea, asi-mismo, implementar ODF en un grupo deagencias, incluida la Oficina deDiscapacidad, para el 1 de enero de 200710 .Después, planea migrar en fases todas lasagencias del Departamento Ejecutivo paraque cumplan con ODF antes de junio del2007.

ODF: el Formatode Documento emergente

a elección de los gobiernos

Marino MarcichDirector General de ODF Alliance

<mmarcich@odfalliance.org><mmarcich@odfalliance.org><mmarcich@odfalliance.org><mmarcich@odfalliance.org><mmarcich@odfalliance.org>

Traducción:Traducción:Traducción:Traducción:Traducción: Piedad Garrido Picazo (Universidad de Zaragoza)

Resumen: una gran cantidad de gobiernos de todo el mundo ha apoyado el Formato de DocumentoAbierto para Aplicaciones Ofimáticas (ODF) desde su adopción por la Organización Internacional parala Normalización (ISO) y la Comisión Electrotécnica Internacional (IEC) como un estándar internacionalen mayo del 2006. El artículo expone un exhaustivo repaso sobre las decisiones políticas de los gobier-nos para cambiar a ODF, las razones por las que los gobiernos están sopesando esta opción, y elamplio efecto de tener gobiernos decididos a desplegar ODF.

Palabras clave: ISO/IES 26300, ODF, ODF Alliance, Open Document Format.

Autor

Marino Marcich es director gerente de la ODF Alliance (Alianza ODF), una coalición de proveedores,gobiernos, universidades, asociaciones, bibliotecas y organizaciones archivísticas dedicada a instruir alos legisladores, administradores de las TI (Tecnologías de la Información) y al público en general sobrelos beneficios y las oportunidades ofrecidos por ODF. Fundada en marzo del 2006, la ODF Alliance hacrecido hasta contar con más de 340 organizaciones de 48 países distintos, <www.odfalliance.org>.

novática nº 184 noviembre-diciembre 2006 37

Formato de Documento Abierto (ODF) monografía

monografía

Vaud (Suiza): Vaud (Suiza): Vaud (Suiza): Vaud (Suiza): Vaud (Suiza): el Distrito Administrativo deVaud está cambiando a ODF. La alcaldíainforma del compromiso de adoptarestándares de software libre, decisión que seestá extendiendo a través de Suiza11 .

1.3. Agencias gubernamentales yotras entidades públicasVarias agencias gubernamentales grandes yentidades públicas utilizan ODF comoestándar de intercambio interno de docu-mentos y en sus relaciones con el público.

Australia:Australia:Australia:Australia:Australia: los Archivos Nacionales de Aus-tralia usan un programa de licencia de códi-go abierto que convierte otros formatos defichero de oficina a ODF con propósitosarchivísticos12 .

India:India:India:India:India: la Comisión Electoral de la India haadoptado ODF a nivel nacional. Otras agen-cias gubernamentales que también lo hanadoptado son las Cortes Allahabad, el Go-bierno de Delhi, el Departamento de Im-puestos, Delhi, la Corporación de Segurosde Vida (entidad gubernamental), y el Ejér-cito de la India.

2. Obtención de apoyo gubernamen-tal para ODFLos gobiernos influyen en el mercado nosólo desde un punto de vista político sinotambién con sus decisiones de compra. Alre-dedor de 50 entidades nacionales, regionalesy municipales de gobierno en todo el mundousan aplicaciones productivas de oficina quesoportan ODF.13

La mayoría de estas migraciones implicaque las aplicaciones soporten el almacena-miento por omisión en formato ODF, lo quees importante, ya que muchas de las solucio-nes que proclaman ser "abiertas" requierenla intervención del usuario para evitar lasopciones por omisión de almacenamientodel fichero en cualquiera de los formatosconsiderados "cerrados". Diseñados con unsesgo hacia el almacenamiento en formatospropietarios (incluida la opción deautoalmacenamiento), este defecto ocultocrea un incremento de la dependencia delusuario que se ve limitado a elegir entre unconjunto cerrado de proveedores.

Austria: Austria: Austria: Austria: Austria: la Ciudad de Viena está migrandoalrededor de 18.000 puestos a OpenOffice yStartOffice, ambos soportan ODF comoopción de guardado por omisión14 .

Brasil:Brasil:Brasil:Brasil:Brasil: el Gobierno brasileño está migrando300.000 ordenadores de sobremesa a Linuxy Open Office que soportan el estándar ODFcon la opción de guardado por omisión eneste formato. El Servicio Postal brasileño hainstalado OpenOffice en 14.000 ordenado-res e intenta migrar otros 32.000 distribui-dos por todo el país.

Francia: Francia: Francia: Francia: Francia: se han migrado a OpenOffice másde 300.000 ordenadores de sobremesa endiversos departamentos gubernamentalesincluidos la Gendarmería Nacional, la Di-rección General de Impuestos y los Ministe-rios de Finanzas, Interior, Infraestructura,Justicia, Agricultura y Cultura15 .

Alemania: Alemania: Alemania: Alemania: Alemania: se han migrado a OpenOffice y aStarOffice más de 50.000 ordenadores desobremesa en diversos niveles de la Adminis-tración Pública alemana. Entre ellos se in-cluyen la Oficina Regional de Impuestos dela Baja Sajonia y Baden-Wurttemberg, y lasciudades de Treuchtlingen, Munich,Swaebisch Hall, Leonberg, e Isernhagen. LaComisión de Monopolio alemana hamigrado a StarOffice16 .

Singapur:Singapur:Singapur:Singapur:Singapur: el Ministro de Defensa ha migrado5.000 puestos a OpenOffice que soporta elFormato de Documento Abierto para apli-caciones ofimáticas de OASIS (OpenDocument), y planea migrar 15.000 ordena-dores más.

3. Soporte de las aplicaciones paraODFLos desarrolladores de software están res-pondiendo a la creciente demanda por partede los clientes e implementando ODF en susproductos. Hoy hay una gran variedad deaplicaciones en el mercado que soportanODF, abarcando desde soluciones de códi-go abierto como OpenOffice y Koffice hastasoluciones de software comercial como elStarOffice para Sun y el Workplace de IBM17 .La lista incluye no sólo suites productivas desoftware de oficina, sino también aplicacio-nes web como el Writely de Google, hojas decálculo y software colaborativo documentalpara el trabajo entre compañías. El crecienteapoyo por parte de los desarrolladores es unindicador de confianza en la pujanza deODF como la elección de los gobiernos parael formato de sus documentos.

4. Por qué los gobiernos están4. Por qué los gobiernos están4. Por qué los gobiernos están4. Por qué los gobiernos están4. Por qué los gobiernos estáncambiando a ODFcambiando a ODFcambiando a ODFcambiando a ODFcambiando a ODFLos documentos son unos de los pilaresfundamentales de los gobiernos modernos yde sus ciudadanos. Estas entidades hacenuso de los documentos para capturar cono-cimiento, almacenar información crítica,coordinar actividades, medir resultados ypermitir la comunicación entre departamen-tos, así como la comunicación entre susnegocios y los ciudadanos. Cada vez es ma-yor el número de documentos que han cam-biado su formato tradicional por un formatoelectrónico.

Para adaptarse a este medio, que está cam-biando continuamente, y a los procesos denegocio, los gobiernos necesitan asegurarsede que van a poder acceder, recuperar y usarregistros críticos, ahora y en el futuro.

Acceso.Acceso.Acceso.Acceso.Acceso. De manera alarmante, los gobier-nos hoy en día pueden no ser ya verdadera-mente dueños de sus propios documentos,ya que pueden perder en un futuro cercano lacapacidad de acceder, modificar y guardardocumentos archivados, o tener dificultadespara abrir documentos más antiguos. Inclu-so si pueden ser abiertos, los documentosson algunas veces completamenteindescifrables porque las especificacionestécnicas con las que fueron construidos noestán disponibles en la actualidad. ODF, alser un estándar duradero y abierto, permiteasegurar que los documentos de una deter-minada entidad guardados en la actualidadno serán tecnológicamente bloqueados niabandonados el día de mañana. Los gobier-nos quieren evitar la dependencia de la tec-nología de un único proveedor para teneracceso a su propia información.

Interoperabilidad. Interoperabilidad. Interoperabilidad. Interoperabilidad. Interoperabilidad. Por estar ante un estándarabierto, ODF permite a los gobiernos sumi-nistrar a los ciudadanos mayor capacidad deelección (acceder a más variedad de tecnolo-gías, modos de suministro y uso de susservicios e información) con independenciadel hardware, sistema operativo y aplicacio-nes. ODF cumple con este requisito ayudan-do a separar el contenido del documento dela aplicación con la que ese documento hasido creado. Este documento puede ser pro-cesado por otras aplicaciones similares confidelidad, sin interferencias de código pro-pietario o cualquier otra restricción.

Elección.Elección.Elección.Elección.Elección. Los gobiernos están con frecuen-cia atados a actualizaciones, estrategias ydecisiones de precios de un único proveedor,algunas veces sin acceso razonable a otrasalternativas viables. Ya que ODF es un ver-dadero estándar abierto, aumenta las opor-tunidades de que múltiples suministradoresde software compitan en funcionalidad yprecio, suministrando a los gobiernos unaamplia gama de opciones a elegir gracias ala competencia entre proveedores, incluyen-do tanto las aplicaciones de software librecomo las aplicaciones de software propieta-rio.

Bajo coste. Bajo coste. Bajo coste. Bajo coste. Bajo coste. ODF es efectivo desde el puntode vista del coste ya que la competenciaexistente en el mercado entre aplicacionesque implementan ODF es muy elevada (in-cluyendo las soluciones de código abierto)con precios competitivos. Los resultados derecientes estudios indican claramente quelos gobiernos están también consiguiendoun ahorro considerable cuando migran susaplicaciones a aplicaciones que soportanODF18 . Esto puede ayudar también a losciudadanos a la hora de elegir una aplica-ción para acceder a la información guberna-mental cuando no sabe por cuál decantarse,ya que hay soluciones sin cargo ya disponi-bles.

novática nº 184 noviembre-diciembre 200638

monografía Formato de Documento Abierto (ODF)

monografía

Innovación.Innovación.Innovación.Innovación.Innovación. ODF suministra un formatoindependiente de la plataforma sobre el quecualquier compañía puede construir y distri-buir aplicaciones nuevas y servicios. Al su-ministrar una línea base de estándares abier-tos, los documentos permanecerán siempreaccesibles incluso después de que se incor-poren innovaciones.

Preservación del patrimonio cultural.Preservación del patrimonio cultural.Preservación del patrimonio cultural.Preservación del patrimonio cultural.Preservación del patrimonio cultural. Cadavez es más frecuente que sean creados yalmacenados en formato digital documen-tos que almacenen información con un im-portante contenido histórico, por lo que esesencial que los gobiernos demuestren sucapacidad para conservar estos documen-tos en ficheros de libre acceso, no sólo parahoy sino para las generaciones futuras. ODFes el único formato de fichero abierto basadoen XML que actualmente se encuentra en elmercado y que satisface esta prueba básicade servicio público.

Manejo de emergencias. Manejo de emergencias. Manejo de emergencias. Manejo de emergencias. Manejo de emergencias. La necesidad del usode estándares abiertos está también aparecien-do en el contexto de la preparación ante emer-gencias. Cuando tuvo lugar el tsunami enTailandia, su gobierno y las agencias interna-cionales fueron incapaces de compartir y ase-gurar el acceso a la información esencial paraayudar al país, porque cada una de estas enti-dades almacenaba su información y documen-tos en formatos diferentes.

Los gobiernos necesitan asegurar que el ac-ceso público a sus servicios esenciales, ensituaciones de emergencia o similares, nodeberá nunca restringirse a los usuarios deuna determinada marca de software.

5. El efecto de la adopción públicade ODF en el mercado más amplioLos gobiernos y las entidades gubernamen-tales son adoptadores estratégicos. Su poderde compra puede ejercer mucha influenciaen el mercado. Los gobiernos son en laactualidad el segundo comprador en poten-cia de Tecnologías de la Información (TI)con 552 mil millones de dólares en el año2006, superado ligeramente por los consu-midores con un total de 700 mil millones dedólares y por delante de otros segmentos dela industria, incluidos finanzas, manufactu-ración y servicios19 .

Sólo en los Estados Unidos, los gobiernoslocales, federales y estatales han anticipadoque habrán gastado alrededor de 150 milmillones de dólares en el 2006 en productosy servicios tecnológicos.

Los gobiernos podrán ejercer una elevadainfluencia en las elecciones tecnológicas so-bre todo a través de su interacción electróni-ca con los ciudadanos. ODF ofrece a losciudadanos una oportunidad de poder elegircómo acceder, suministrar y usar la informa-ción y los servicios del gobierno, que cadadía son más numerosos en modo on-line. Lamovilidad es el factor estratégico de las agen-das TI.

Como formato de documento portable queno está vinculado a ningún tipo de aplica-ción ni de plataforma, ODF puede ser uncomponente esencial para una arquitecturaorientada a servicios que los gobiernos estánesforzándose por desarrollar.

Notas

1<http://www.gartner.com/resources/140100/140101/iso_approval_of_oasis_ opendo_ 140101. pdf>.2<http://www.siia.net/govt/docs/pub/Belgium_FEDICT_OpenForumEurope_060704.pdf>.3<http://www.e-hrvatska.hr/repozitorij/dokumenti/downloads/Open_Source_Software_Policy.pdf>.4<http://itpol.dk/sager/offpol/b103_eng>.5<https://www.ateliers.modernisation.gouv.fr/ministeres/domaines_d_expertise/architecture_fonctio/public/rgi/folder_contents>.6<http://www.openmalaysiablog.com/2006/11/odf_as_a_malays.html>.7<http://odin.dep.no/filarkiv/254956/eNorway_2009.pdf>.8<http://www.hispalinux.es/files/mocion_ consejo_gobierno_english.pdf>.9<http://www.mass.gov/?pageID=itdterminal&L=4&L0=Home&L1=Policies%2c+Standards+%26+Guidance&L2=Enterprise+Architecture&L3=Enterprise+ Technical+Reference+Model+-+ServiceOriented+Architecture+(ETRM+v3.5)&sid=Aitd&b=terminalcontent&f=policies_standards_ETRMVersion3.5InformationDomain&csid=Aitd>10<http://www.mass.gov/?pageID=itdmodu lechunk&&L=3&L0=Home&L1=Open+Initiatives&L2=OpenDocument&sid=Aitd&b=terminalcontent&f=accessibility_odf_accessibility_midyear_ltr&csid=Aitd>.11<http://opendocumentfellowship.org/node/214>.12<http://www.naa.gov.au/recordkeeping/preservation/digital/xml_data_formats.html>.13<http://opendocumentfellowship.org/government/precedent>.14<http://www.wien.gv.at/english/edp oss.htm>15<http://wiki.services.openoffice.org/wiki/Market_Share_Analysis>.16<http://wiki.services.openoffice.org/wiki/Market_Share_Analysis>.17<ht tp : / /en .w ik iped ia .o rg /w ik i /L is t_o f_applications_supporting_OpenDocument>.18<http://www.odfalliance.org/resources/PrelimCostAssess20061109.pdf>.19<http://www.witsa.org/digitalplanet/2006/DP2006_ExecSummary.pdf>.

YA PUEDES ABRIR TU BLOG EN LA WEB DE ATI

COMPARTE TUS EXPERIENCIAS PERSONALES Y PROFESIONALES

http://www.ati.es/blog

Servicio reservado a usuarios de ATInet

http://www.ati.es/ATInet/alta

novática nº 184 noviembre-diciembre 2006 39

Formato de Documento Abierto (ODF) monografía

monografía

1. La actuación del Programa IDAEl Programa IDA (Interchange of DataBetween Administrations), desarrollado en-tre 1999 y 2004, perseguía el establecimientode servicios transeuropeos entre administra-ciones para apoyar la aplicación de políticasy actos comunitarios, la comunicacióninterinstitucional en la Unión Europea y elproceso de decisión comunitario, así comoel establecimiento de las acciones y medidashorizontales necesarias para facilitar el des-pliegue de los citados servicios.

En mayo de 2003, IDA emprendió una líneade acción orientada a promocionar la utili-zación de los formatos abiertos para el inter-cambio de documentos. La decisión de ac-tuar en este terreno se adoptó por dos razo-nes fundamentales:

En primer lugar se detectó, en aquel mo-mento, por un lado, una baja interopera-bilidad entre aplicaciones ofimáticas, conefecto insatisfactorio para el desarrollo de laadministración electrónica; y, por otro, unafalta de apoyo a formatos abiertos y estándarde documentos en soporte electrónico.

En segundo lugar, cuando los expertosdel Programa IDA examinaron el estado desituación de la cuestión, se consideró que losdocumentos intercambiados entre las admi-nistraciones públicas y los ciudadanos debe-rían encontrarse en un formato tal que noobligara a éstos a la utilización de unosproductos de software específicos y que ase-gurara también la accesibilidad permanentea los mismos.

IDA aprobó en enero 2004 el análisis compa-rativo de los estándares de formatos de docu-mentos disponibles y, en particular, de losestándares existentes o emergentes de formatosabiertos de documentos y de la posible evolu-ción del mercado en este terreno.

Este análisis, conocido como Informe Valoris[4], realizaba valiosas aportaciones, entrelas que cabe destacar la identificación deaquellas cualidades que sirven para deter-minar el formato de documento ideal. Talescualidades son las ocho siguientes: abierto,no-binario, modificable, fidelidad de lapresentación,interoperabilidad multipla-taforma, soporte de características de losprocesadores de textos existentes, soporte derequisitos emergentes y amplia adopción.

Posteriormente, en marzo de 2004, se con-vocó a los mayores actores del mercado(Microsoft y SUN), se les invitó a comentarel citado Informe Valoris y se les dio audien-cia para que pudieran presentar y defendersus respectivos puntos de vista, así como adebatir la cuestión con los expertos del Pro-grama IDA.

Estas actuaciones culminaron el 25 de mayode 2004, cuando el Comité de Telemáticaentre Administraciones, de 25 Estados miem-bros, comité gestor del Programa IDA, res-paldó las recomendaciones relativas a lapromoción de la utilización de los formatosabiertos de documentos, elevadas por sugrupo de expertos en la materia [2].

Al formular estas recomendaciones se reco-noció la especial responsabilidad del sectorpúblico europeo en cuanto a salvaguardar laaccesibilidad de su información, la necesi-dad de mejorar las interacciones con losciudadanos y las empresas, así como el pesodel sector público como comprador de pro-ductos y servicios.

También, y como resultado del proceso deanálisis y estudio realizado, se identificaronlos pasos dados por la industria, señalandola publicación de los formatos OpenOffice.org y WordML; se concluyó que no esnecesario que todos los documentos seaneditables y que en el caso de documentos que

hayan de ser editados, XML ofrece el mejorescenario de separación de contenido, es-tructura, semántica y presentación; que elsector público no debe forzar a la utilizaciónde un producto determinado y que debepromocionarse un formato que puedaimplementarse en diversas plataformas, queno sea discriminatorio de los actores delmercado y que ofrezca igualdad de oportu-nidades para su implementación; y, final-mente, se dio la bienvenida a la normaliza-ción del formato de OpenOffice.org porOASIS.

Las recomendaciones propiamente dichasse formularon a la luz de las limitaciones a lafecha de su emisión en cuanto a los formatosde documentos existentes y fueron dirigidasa los actores con capacidad de influir en lamateria.

En consecuencia, se recomendaba lo siguien-te:1

Que el Comité Técnico de OASIS conside-re si se da la necesidad y oportunidad paraque el emergente estándar OASIS de Forma-to Abierto de Documento sea extendido parapermitir los esquemas definidos por el usua-rio.

Que los actores de la industria noinvolucrados a la fecha en el estándar OA-SIS de Formato Abierto de Documento con-sideren la participación en el proceso deestandarización a fin de incentivar un con-

Promoción del uso de losformatos abiertos de documentos

por los Programas IDA e IDABC

Miguel A. Amutio GómezJefe de Area de Planificación y Explotacióndel Ministerio de Administraciones Públicas,Socio de ATI

<miguel.amutio@map.es><miguel.amutio@map.es><miguel.amutio@map.es><miguel.amutio@map.es><miguel.amutio@map.es>

Miguel A. Amutio Gómez, 2007. Esta presentación se distribuye bajo la licencia"Reconocimiento-CompartirIgual 2.5 España" de Creative Commons, disponibleen <http://creativecommons.org/licenses/by-sa/2.5/es/deed.es>

Resumen: este artículo trata de la actuación de los Programas comunitarios IDA (Interchange ofData Between Administrations) e IDABC (Interoperable Delivery of Pan-European eGovernmentServices to Public Administrations, Business and Citizens) en materia de promoción de los formatosabiertos para el intercambio y almacenamiento de documentos, sean éstos editables o no. El 25de mayo de 2004 el comité gestor del Programa IDA respaldó las recomendaciones relativas a lapromoción de la utilización de los formatos abiertos de documentos. El 6 de diciembre de 2006 elcomité gestor del Programa IDABC ha respaldado las conclusiones y recomendaciones sobre losformatos abiertos de documentos que actualizan y dan continuidad a las anteriormente emitidaspor IDA a la luz del estado de situación actual.

Palabras clave: formatos abiertos de documentos, IDA, IDABC.

Autor

Miguel A. Amutio Gómez es Licenciado en Informática por la Universidad de Deusto (1988). Se incor-pora a la Administración General del Estado en 1994. Es miembro de la delegación española en elComité gestor de los Programas comunitarios IDA (1999-2004) e IDABC (desde 2005). Es Jefe delProyecto "Criterios de seguridad, normalización y conservación de las aplicaciones utilizadas para elejercicio de potestades", entre otras actuaciones y proyectos.

novática nº 184 noviembre-diciembre 200640

monografía Formato de Documento Abierto (ODF)

monografía

senso más amplio de la industria en relacióncon el citado formato.

Que se considere la elevación del emergen-te estándar OASIS de Formato Abierto deDocumento a un organismo oficial de nor-malización tal como ISO.

Que Microsoft considere comprometersepúblicamente a publicar y proporcionar ac-ceso no discriminatorio a las futuras versio-nes de sus especificaciones de WordML.

Que Microsoft debiera considerar el inte-rés de elevar los formatos XML a un organis-mo internacional de normalización de suelección.

Que Microsoft valore la posibilidad deexcluir los componentes no-XML de los do-cumentos WordML.

Se anima a la industria a que proporcionefiltros que permitan que los documentosbasados en las especificaciones WordML yen el emergente estándar OASIS FormatoAbierto de Documento se puedan leer y es-cribir entre aplicaciones a la vez que se man-tiene un alto nivel de fidelidad al contenido,la estructura y la presentación. Estos filtrosdebieran encontrarse disponibles para todoslos productos.

Se anima a la industria a que proporcionelas herramientas y servicios adecuados quepermitan al sector público considerar la via-bilidad y los costes de transformación de susdocumentos a los formatos basados en XML.

Se anima al sector público a que propor-cione su información a través de diversosformatos. Cuando por unas u otras razonesse haya de usar solamente un formato nomodificable, este formato debiera ser aquélalrededor del cual hay un consenso de laindustria, demostrado por la adopción delformato como un estándar.

Tras la emisión de las recomendaciones, laDirección General de Empresa (DG ENTR)de la Comisión Europea invitó a los princi-pales productores de software a que trabaja-ran en pos de una mayor interoperabilidaden los formatos de documentos. En respues-ta a esta llamada, IBM, Microsoft y SUNexpresaron su compromiso de avanzar en lacitada dirección [5].

2. La actuación del ProgramaIDABCEl Programa IDABC (Interoperable Deliveryof Pan-European eGovernment Services toPublic Administrations, Business andCitizens) a desarrollar entre 2005 y 2009como sucesor del Programa IDA, persigue,en un nuevo contexto que incluye a los ciuda-danos y a las empresas, la identificación,promoción y desarrollo de servicios que apo-yan la aplicación de actos y políticas comu-nitarios, la comunicación interinstitucionalen la Unión Europea y el proceso de decisióncomunitario, así como de las medidas hori-zontales que facilitan el despliegue de esosservicios [6] [8].

IDABC también ha incluido en su Programade Trabajo la promoción de los formatosabiertos para el intercambio de documentosa fin de facilitar los intercambios de docu-mentos en el nivel paneuropeo, pues si biense han producido avances notables graciasal impulso del Programa IDA, se consideraque los problemas de interoperabilidad si-guen existiendo [3] [7].

Se persigue que los Estados miembros y losactores de la industria se impliquen en eldebate sobre la cuestión, en la identificaciónde soluciones, así como en la promoción dela concienciación del sector público en cuan-to a la adopción de formatos abiertos dedocumentos. Así, IDABC ha trabajado en laelaboración de unas conclusiones y reco-mendaciones sobre los formatos abiertos dedocumentos que actualicen las emitidas ensu día por el Programa IDA a la luz delestado de situación a la fecha.

El 6 de diciembre de 2006 el Comité gestordel Programa IDABC ha adoptado las con-clusiones y recomendaciones sobre losformatos abiertos de documentos, elevadaspor su grupo de expertos en la materia [1].

Estas conclusiones y recomendaciones re-conocen la especial responsabilidad del sec-tor público europeo en cuanto a asegurar laaccesibilidad a su información, se realizancon vistas a racionalizar y facilitar lasinteracciones con los ciudadanos y las em-presas, tienen la intención de desbloquear lainformación contenida en documentos delsector público y tienen presente la importan-cia del sector público como comprador deservicios y productos de tecnologías de lainformación.

Las conclusiones y recomendaciones reco-gen en cinco páginas los antecedentes, elobjetivo, los progresos realizados en materiade normalización, los progresos realizadospor las administraciones públicas y los pro-blemas a ser resueltos.

Cabe destacar los siguientes aspectos:Las administraciones públicas en Europea

entienden que el intercambio y almacena-miento de documentos en soporte electróni-co debiera basarse en formatos abiertos dedocumentos.

Tales formatos han de ser definidos en unproceso abierto a todas las partes interesadasy encontrarse disponibles para todos los acto-res interesados y competentes de forma quepuedan ser implementados sin restricciones.

Se considera que estas condiciones han deestimular la competencia y la innovación enel campo de la gestión de documentos.

Se expresa la preferencia de que estosformatos abiertos para el intercambio y al-macenamiento de documentos se encuen-tren sujetos a normalización formal a través

de los procedimientos internacionales denormalización.

En relación con los progresos realizadospor las administraciones públicas, se apuntaque administraciones en varios Estadosmiembros (ej. Bélgica, Dinamarca, Francia,España -Extremadura-, Italia) han adopta-do estrategias para la introducción de losformatos abiertos de documentos.

Se tienen presentes desarrollos recientes enmateria de normalización de manipulación yalmacenamiento de documentos; en concreto,se refieren a la publicación de la norma ISO/IEC 26300 (International Organization forStandardization/International ElectrotechnicalCommission) "Open Document Format forOffice Applications", basada en la especifica-ción OASIS ODF; la aprobación por la Asam-blea General de ECMA (European ComputerManufacturers Association) del formatoMicrosoft Office Open XML como ECMA376 y el anuncio de elevar la especificación aISO; la publicación de la norma ISO 19005"Document management – Electronicdocument file format for long term conservation– Part 1, Use of PDF 1.4 (PDF/A1) ".

Se subraya que, a pesar de estos desarro-llos recientes, permanecen problemas decompatibilidad entre la nueva norma ISO/IEC 26300 y los formatos del producto deofimática dominante. Se expone que la pers-pectiva de una segunda norma ISO no ali-viará estos problemas y que los filtros, plug-ins y conversores no lo resuelven todo.

Tras lo cual se formulan las siguientesrecomendaciones:

6. RECOMENDACIONES 2

A la vista de la situación actual, se invita a lasadministraciones:

6.1. A realizar un máximo uso de formatosabiertos para el intercambio y almacena-miento de documentos internacionalmentenormalizados para la comunicación internay externa.

6.2. A utilizar solamente formatos que pue-dan ser manejados por una variedad de pro-ductos, evitando de esta forma forzar a susinterlocutores al uso de productos específi-cos. Cuando el uso de formatos propietariossea inevitable, se proporcionarán formatosinternacionalmente normalizados de formaalternativa junto con formatos propietarios.

6.3. A adaptar, donde proceda, directrices yreglamentaciones nacionales, teniendo pre-sente la llegada de normas internacionalesen este terreno.

6.4. A considerar la definición de requisitosmínimos en relación con las funcionalidadesde los formatos abiertos para el intercambiode documentos con vistas a la compatibili-dad entre aplicaciones.

novática nº 184 noviembre-diciembre 2006 41

Formato de Documento Abierto (ODF) monografía

monografía

6.5. A definir directrices para el uso deformatos de intercambio y almacenamientode documentos editables y no editables paradiferentes propósitos.

Se invita a la industria, a las asociacionesempresariales y a los organismos internacio-nales de normalización:

6.6. A trabajar juntos hacia una norma inter-nacional de documento abierto, aceptablepara todos, para documentos editables y noeditables respectivamente.

6.7. A desarrollar aplicaciones que puedanmanejar todos las normas internacionalesrelevantes, dejando a los usuarios la eleccióndel formato a ser utilizado "por defecto".

6.8. A evitar que la finalidad de los formatosabiertos para intercambio y almacenamien-to de documentos sea invalidada por la ofer-ta de extensiones a las normas internaciona-les relevantes como formatos por defecto.

6.9. A formular propuestas para pruebas deconformidad y a desarrollar herramientasadecuadas con el fin de salvaguardar lainteroperabilidad entre aplicaciones.

6.10. A continuar la mejora de las normasexistentes, teniendo en cuenta necesidadesadicionales tales como los documentos fir-mados electrónicamente.

Referencias

[1] European Commission. PEGSCO approval onconclusions and recommendations on opendocument formats. <http://ec.europa.eu/idabc/en/document/3428/5644>, <http://blade.eurodyn.com/idabc/servlets Doc?id=26971>.[2] European Commission. TAC approval onconclusions and recommendations on opendocument formats. <http://ec.europa.eu/idabc/en/document/3439/5585#recommendations>.[3] European Commission. IDABC Promotion ofOpen Document Exchange Format. <http://europa.eu.int/idabc/en/document/3428/5644>.[4] VALORIS. Comparative Assessment of OpenDocuments Formats Market Overview. <http://ec . eu ropa .eu / i dabc /en /documen t /3439 /5585#ODF>.[5] European Commission. Responses from IBM,Microsoft and SUN to the TAC recommendations-Sept./Nov. 2004. <http://ec.europa.eu/idabc/en/document/3439/5585#responses>.[6] European Commission. The Programme IDABC.<http://europe.eu.int/idabc/>.[7] European Commission. IDABC workprogramme 2005-2009. <http://ec.europa.eu/idabc/en/document/5101/3>.[8] Ministerio de las Administraciones Públicas.La construcción de los servicios pan-europeos deAdministración electrónica. <http://www.csi.map.es/csi/pg3315.htm>.

1Traducción no oficial de la versión original enlengua inglesa.2Traducción no oficial de la versión original enlengua inglesa.

Notas

novática nº 184 noviembre-diciembre 200642

monografía Formato de Documento Abierto (ODF)

monografía

Una historia resumida de losestándares abiertos en Dinamarca

John GøtzeCopenhagen Business School, Dinamarca

<john@gotzespace.dk><john@gotzespace.dk><john@gotzespace.dk><john@gotzespace.dk><john@gotzespace.dk>

1. Introducción1. Introducción1. Introducción1. Introducción1. IntroducciónEn el campo de la e-Administración, Dina-marca es visto casi siempre como el lídercuando se compara con otras naciones. Senos considera la sociedad más e-preparadacon los ciudadanos más e-formados. Tene-mos PKI y firmas digitales, aprovisiona-miento electrónico (e-procurement) y factu-ras electrónicas, registros digitales y basesde datos en masse, etcétera. Dimamarca estambién señalada a menudo como el máxi-mo "país Microsoft": no sólo hospeda ladivisión de desarrollo de Microsoft más gran-de de Europa, sino que esta empresa estambién un monopolio de facto en el gobier-no danés y en la sociedad en general.

Los estándares abiertos han figurado en laagenda política de Dinamarca durante mu-chos años, provocado parcialmente por lasituación con Microsoft y otros monopolios,pero también como parte de un proceso deaperturización1 ampliamente apoyado.

Utilizo el concepto de aperturización comoun término global para una estrategia detransformación deliberada donde la aplica-ción de estándares abiertos representa unpapel principal, y en donde el objetivo finales crear un ecosistema abierto de TIC (Tec-nologías de la Información y la Comunica-ción) saludable y sostenible, innovador ycreativo, inclusivo y potenciador. El concep-to de aperturización se convirtió en comúndentro del Open ePolicy Group cuando sellevó a cabo el Roadmap for Open ICTEcosystems [1]. En el Roadmap describi-mos el proceso de aperturización como unaestrategia de trébol, donde las hojas sonestándares abiertos, código abierto y arqui-tectura orientada a servicios (SOA).

2. El caso danés2. El caso danés2. El caso danés2. El caso danés2. El caso danésHace dos años, el gobierno danés empezó aexigir a todas las compañías que proveíanbienes o servicios al estado que emitieranelectrónicamente sus facturas. Este proyectorecibió un premio de la Unión Europea (UE) ala innovación en una conferencia ministerial,no porque fuera brillante técnicamente ha-blando sino por la resolución con la que fuepuesto en marcha de manera obligatoria. Losministros de la UE quedaron impresionadospor su estrecha relación con el ahorro de cos-tes, algo que hasta entonces habían eludido lamayor parte de los e-proyectos europeos, comoasí era admitido.

De hecho, efectivamente hubo una decisióntécnicamente inteligente en el proyecto da-nés de facturas electrónicas. El gobiernodanés adoptó el estándar UBL (UniversalBusiness Language) de OASIS y, de estamanera, no sólo ayudó a UBL a alcanzar sumasa crítica, sino que también permitió quela solución danesa estuviera lista para una

Traducción: Traducción: Traducción: Traducción: Traducción: Ramón López Gadea (socio de ATI)

adopción más amplia e internacional. Hoyson varios los países, especialmente en laUE, que también están adoptando UBL.Durante este proceso Dinamarca aprendió quela obligatoriedad no será universalmente po-pular, pero que se consiguen elevados nivelesde eficacia y potenciales mejoras en el serviciohaciendo los estándares imperativos. Comodijo un periodista británico [2], "la agresividadvikinga siempre gana: es más eficiente".

3. Común y abierto3. Común y abierto3. Común y abierto3. Común y abierto3. Común y abiertoPor supuesto, es un punto importante atener en cuenta, que UBL es un estándarabierto. Desafortunadamente, quizás digaalguien, la importancia de este detalle no hasido del todo clara en el proceso danés,donde el principal interés del gobierno esque fuera un estándar común y obligatorio.

Pero se hizo evidente para los legisladoresque no es suficiente con ser común, y que losestándares deberían ser tanto comunes comoabiertos. Sin embargo, esto provocaba mu-chos y demasiado frecuentes debates sobredefiniciones: ¿qué es un estándar abierto?

No ayudaba el hecho de que Microsoft esco-giese a Dinamarca para la fase inicial deabrir sus formatos de documento, durante lacual los XML Schemas para WordML ysimilares fueron publicados en el repositorioXML del gobierno danés. ¿Éso los convertíaen un estándar abierto?

4. Política de estándares abiertos4. Política de estándares abiertos4. Política de estándares abiertos4. Política de estándares abiertos4. Política de estándares abiertosEn Dinamarca, el tema de los "estándaresabiertos" se convirtió en problema de políti-ca "real" en 2004 cuando Morten HelvegPetersen, desde un pequeño partido de laoposición (el "MP"), lo lanzó en el Parla-mento basándose en una propuesta para eluso de estándares abiertos en la Administra-ción. Esto provocó un largo debate. Resulta-do: el 2 de junio de 2006, el parlamentodanés (Folketinget) aprobó unánimementeuna Resolución Parlamentaria sobreEstándares Abiertos (B103) que decía (se-gún mi traducción): El Parlamento imponeal gobierno el deber de asegurarse de que eluso de las TI (Tecnologías de la Informa-

ción) en el sector público, incluído el uso desoftware, esté basado en estándares abier-tos.

Seguía especificando que: "El Gobierno de-bería adoptar y mantener un conjunto deestándares abiertos el 1 de enero de 2008, otan pronto como sea técnicamente posible,que pueda servir como inspiración para elresto del sector público. Los estándares abier-tos deberían ser parte de las TI públicas y dela adquisición de software con objeto depromocionar la competencia".

En los comentarios se sugiere que ésto siga elmodelo "cumplir o explicar" (Nota del Traduc-Nota del Traduc-Nota del Traduc-Nota del Traduc-Nota del Traduc-tortortortortor: esta expresión denomina una práctica degobierno corporativo europea que significaque una compañía debe cumplir con el Codigode Prácticas Corporativas o bien explicar porqué escoge otra alternativa. Ver por ejemplo <http://www.nues.no/English/The_comply_or_explain_principle/>).

Pero en general, la resolución dice: "El Go-bierno debería asegurar que toda informa-ción y datos digitales que el sector públicointercambie con los ciudadanos, compañíase instituciones, esté disponible en formatosbasados en estándares abiertos".

Sin embargo, hay que recordar que el gobiernose opuso a la resolución hasta el último minu-to, pero remoloneando: unos dicen por que sedieron cuenta de que iban a perder la votación,otros por que era parte de una táctica más sutil.De cualquier forma la resolución fue aproba-da, poniendo en marcha una apretada agendapara los estándares abiertos en el gobiernodanés. El ministro responsable, Helge Sander,Ministro de Ciencia, Tecnología e Innovación,tiene todavía pendiente presentar un plan depuesta en marcha.

5. Cumplir o Explicar5. Cumplir o Explicar5. Cumplir o Explicar5. Cumplir o Explicar5. Cumplir o ExplicarEl ministro ha confirmado en varias ocasionesque se utilizará el modelo "cumplir o explicar",pero todavía no ha especificado cómo lo apli-cará. No hay por ahora un lugar establecidopara "explicar" cómo se hacen las cosas, así queserán necesarios algunos cambios

Resumen: este artículo analiza los desarrollos actuales y recientes en Dinamarca, donde los estándaresabiertos se han convertido en un tema de política central. Aunque éste país tiende a liderar esta vía deapertura a gran escala, es muy improbable que lo haga hasta sus últimos extremos.

Palabras clave: aperturización, Dinamarca, e-government, estándares abiertos, interoperabilidad,OpenDocument.

Autor

John Gøtze ha trabajado en Tecnología Gubernamental, Arquitectura Empresarial y Estándares Abiertosdurante más de quince años. Hoy en día es consultor independiente y escritor, profesor asociado en laCopenhagen Business School y miembro del staff de OASIS, Organization for the Advancement ofStructured Information Standards. También es miembro del Open ePolicy Group.

novática nº 184 noviembre-diciembre 2006 43

Formato de Documento Abierto (ODF) monografía

monografía

institucionales si se va a aplicar este principio.También debería ser contemplado como unprincipio que habría de ser aplicado en contra-tos, concursos y suministros. Pero tambiénaquí hay dudas: ¿qué es lo que se supone queel proveedor debe cumplir? La cuestión, porsupuesto, es que este "cumplimiento" debeaplicar allí donde sea necesario. En muchassituaciones esto significa cumplir ciertosestándares específicos. En tal caso, ¡muchosvendedores tendrían mucho que "explicar"!

En el caso danés de las facturas electrónicas laúnica opción era "cumplir", pero para que fuerauna solución realista y operativa el gobiernoeligió patrocinar un "intermediario",un servi-cio de conversión a través de las llamadas"read-in bureaus" (agencias de escaneo), demanera que el cumplimiento se asegurabamediante esa solución intermediaria.

El ejemplo danés demuestra que es posibleimponer el uso de estándares a gran escala.Con todo, también el mercado de los fabri-cantes reaccionó positivamente y percibió el"cumplimiento" en sus productos como unanecesidad.

6. ¿Gobiernos liderando el movi-6. ¿Gobiernos liderando el movi-6. ¿Gobiernos liderando el movi-6. ¿Gobiernos liderando el movi-6. ¿Gobiernos liderando el movi-miento?miento?miento?miento?miento?Se puede hablar mucho y bien de que hayansido los gobiernos los que hayan liderado elmovimiento de la adopción de estándares,pero sabemos también que ello conlleva pe-ligros inherentes. Los gobiernos no son siem-pre los más rápidos en moverse, y una vezque han tomado la decisión, puede serlescasi imposible hacer cambios y adaptarse anuevas circunstancias. La historia demues-tra de que esto es un reto real: por ejemplo,el ahora antiguo protocolo de correo electró-nico X.400, ha sido mantenido por bastantesgobiernos mucho después de que hubieracesado su existencia en la industria.

Los partidarios de ODF han creado la ODFAlliance [3], cuya misión es que los gobiernosadopten ODF. Aunque cuentan con mi simpa-tía, quiero resaltar que es de importancia crucialque consigamos una más amplia adopción deestándares como ODF. Si tan sólo es un están-dar gubernamental, fracasará. Necesita quesea adoptado por la sociedad en su conjunto.Durante el proceso B103, el Ministro deCiencia anunció que su ministerio y otrospocos más iban a iniciar un proyecto pilotocon ODF. Éste debería asegurar que losdocumentos publicados en sus sedes webestarían disponibles en ODF además de otrosformatos, ya que ellos a menudo publicansólo en Word. En poco tiempo, el ministerioha remozado su sede con unos pocos docu-mentos y parece que han aprendido a nopublicar en Word.

7. ¿Unificar o dividir?7. ¿Unificar o dividir?7. ¿Unificar o dividir?7. ¿Unificar o dividir?7. ¿Unificar o dividir?Aunque tendría mucho sentido hacer hincapiéen la idea de que dichos estándares podrían serunificadores, algo en lo que todos estamos deacuerdo, la realidad es bastante diferente. Elactual desarrollo de los estándares abiertospara formatos de documentos de oficina mues-

tra las mayores ramificaciones de laestandarización, la cual es usada tanto paraunir como para dividir [4] a personas, merca-dos, regiones geopolíticas y tecnologías.

¿Unificar? Sí, Sun Microsystems, IBM ymuchos otros se han unido en torno a OpenDocument Format (ODF), que ahora es unestándar ISO mantenido activamente porOASIS. ¿Dividir? Sí, porque hay más de unestándar. Por ahora, tal y como sabemos, elnuevo formato de documento de Microsoftpara sus paquetes Office, Office Open XML,es un estándar oficial publicado por ECMA,la European Computer Manufacturer’sAssociation que se ha convertido en un con-sorcio de estandarización. También Chinatiene su propio estándar UOF (UniformOffice Format). El presidente y CEO deCompTIA’s John Venator comentó en unacarta [5] a ECMA: "La competencia entremúltiples estándares abiertos de documentomejorarán la innovación en formatos eincrementarán la flexibilidad y lainteroperabilidad, todo para beneficio de losconsumidores de software".

Esta visión es claramente un argumento afavor de los intereses de los proveedores (delos que CompTIAS es representante).Una visión alternativa es que la competen-cia es buena, pero sólo es saludable cuandoocurre entre productos y raramente entreestándares. Por el contrario, a menudo esuna buena decisión de negocio seleccionar,si no obligar, ciertos estándares.

8. ¡Veamos los costes!8. ¡Veamos los costes!8. ¡Veamos los costes!8. ¡Veamos los costes!8. ¡Veamos los costes!Rambøll Management, una consultora da-nesa, realizó por encargo de la Danish OpenSource Business Association (OSL) un in-forme sobre los costes derivados de cambiara estándares abiertos para formatos de do-cumentos en la Administración danesa. Elinforme establece tres escenarios para eldesarrollo:Escenario 1: Microsoft Office con ECMAOffice Open XML: costaría 380 millones decoronas durante 5 años con migración a MSOffice 2007; 105 millones de coronas si seusa la versión actual con un adaptador.Escenario 2: OpenOffice.org y ODF. costa-ría 255 millones de coronas durante 5 años,cubriendo todos los costes de migración másel de las licencias de Microsoft ya existenteshasta su retirada.Escenario 3: Microsoft Office (con un adapta-dor) y ODF. Sólo tendría costes marginalmentesuperiores a los del escenario 1.La Open Source Business Association esti-ma que la Administración completa (inclu-yendo las locales) podría ahorrar 550 millo-nes de coronas (unos 74 millones de euros alcambio actual) migrando a OpenOffice.orgy ODF.

9. ¿Abierto? No me lo creoEn diciembre de 2006, IDC Nordic presentólos resultados de una encuesta que habíanllevado a cabo entre compañías y gobiernosnórdicos sobre formatos de documentos.Per Andersen, director de gestión en IDC

Nordic, dijo: "Creemos que va a existir múl-tiples estándares abiertos de documentos(igual que en el caso de los formatos propie-tarios) y que cada cual reflejará determina-das necesidades del mercado". El informe de4.200 dólares de IDC fue publicado gratui-tamente en la sede OpenXMLDeveloper.orgde Microsoft [6]. Supuestamente, Microsoftquiere que el mundo conozca sus descubri-mientos, que IDC resume en: "Las compa-ñías en general no consideran ODF másabierto que OpenXML o viceversa. En gene-ral, las compañías están asignando mayorimportancia para ellos a OpenXML que aODF a la hora de adquirir software". IDCsin embargo también hace ver que ODF tienesus mayores márgenes de adopción entreorganizaciones públicas, y creen que estehecho refleja la posición de ODF como ase-gurador de la "comunicación libre entre elsector público y los ciudadanos". La conclu-sión a la que llega IDC es que: "No creemosque haya problemas per-se en la coexistenciade dos estándares de documento".

10. Mi conclusión10. Mi conclusión10. Mi conclusión10. Mi conclusión10. Mi conclusiónAunque Dinamarca tiende a liderar esta víade aperturización a gran escala, es muy im-probable que lo haga hasta sus últimos ex-tremos. La probable evolución tenderá haciaunas directivas gubernamentales pragmáti-cas más o menos alineadas con las deMicrosoft, conviviendo con los intentos deaperturización. Por otro lado, existen bue-nos y sólidos business case2 con ODF, y unMinisterio de Finanzas a la busca de buenosbusiness case, así que puede ocurrir cual-quier cosa.

Referencias

[1] <http://cyber.law.harvard.edu/epolicy/>.[2] <http://technology.guardian.co.uk/online/insideit/story/0,,1694624,00.html>.[3] <http://odfalliance.org/>.[4] ”Unificador o Divisor” es el tema del siguientenúmero de Standards Edge, ver <http://www.thebolingroup.com/standards_series.html>.[5] <http://www.intelligententerprise.com/showArticle.jhtml?articleID=196602143>.[6] <http://openxmldeveloper.org/archive/2006/11/27/IDC_Open_Document_Standards.aspx>.

1 Después de consultar con el propio autor, hemosdecidido traducir "openization", el neologismo que élusa en inglés, por "aperturización" un termino nove-doso que, según podemos ver buscando en la Red, seestá ya usando en castellano en otros ámbitos comoen el político por ejemplo. John Gøtze nos indica que"openization" surgió en una reunión del Open ePolicyGroup, una Red global de expertos en tecnología a laque él pertenece <http://en.wikipedia.org/wiki/Open_ePolicy_Group> y que a partir de entonces lo estánusando para denominar el proceso progresivo deadopción tecnológica no solamente de estándaresabiertos sino también de código abierto y de arquitec-turas abiertas u orientadas a servicios.2 El autor se refiere aquí a los buenos resultadoseconómicos (ahorros de costes, etc.) que ha supues-to la utilización de ODF como estándar de formato dedocumento en las experiencias ya realizadas.

Notas del editor

novática nº 184 noviembre-diciembre 200644

monografía Formato de Documento Abierto (ODF)

monografía

Con fecha de 25 de julio de 2006, la Adminis-tración Regional de Extremadura recibió,por parte del Consejo de Gobierno, la ordende establecer los formatos OASIS ODFOASIS ODFOASIS ODFOASIS ODFOASIS ODF yPDF/APDF/APDF/APDF/APDF/A como los formatos oficiales dentrode la Administración Pública. Este hecho, degran repercusión en medios nacionales yextranjeros, no ha sido un hecho casual.Supone un avance más hacia la integraciónde la Sociedad de la Información y del Cono-cimiento en nuestra región y, de modo máspreciso, supone el paso de más trascenden-cia hacia la mejora de los servicios públicosa través de las nuevas tecnologías: la utiliza-ción de formatos estándares y abiertos. Eluso de un lenguaje común.

Pero debemos irnos años atrás para entenderen su completa dimensión este acuerdo delConsejo de Gobierno. Y es que la Junta deExtremadura lleva desde antes del año 2000empeñada no sólo en participar de las ventajasde lo digital, sino en ser protagonista de sudestino: estamos participando en la revoluciónde las nuevas tecnologías abriendo puertas quenadie había abierto antes, desbrozando cami-nos que se adapten a nuestros objetivos.

La Administración Autonómica está ejecu-tando desde 1998 un Plan Estratégico Re-gional para el Desarrollo de la Sociedad dela Información en todos los sectores socio-económicos de Extremadura.

El Plan de Alfabetización Tecnológica ySoftware Libre (PAT) tiene como objetivo laincorporación a la Sociedad de la Informa-ción de aquellos sectores de la poblaciónque, por condicionantes sociales, económi-cos y geográficos, podían quedar al margende la revolución tecnológica. Para ello elPAT ha puesto a disposición de los ciudada-nos el conocimiento de las Tecnologías de laInformación y la Comunicación y el soft-ware libre a través de la creación de 33"Nuevos Centros del Conocimiento" reparti-dos por toda la región, especialmente enlocalidades del ámbito rural.

"Vivernet", proyecto dirigido a la implanta-ción de la Sociedad de la Información en elmundo empresarial, apoya la creación deempresas de base tecnológica y la incorpora-ción de las nuevas tecnologías y el softwarelibre en el sector.

El Centro de Fomento de Nuevas Iniciativas,

a su vez, tiene como objetivo la adaptaciónde la estrategia extremeña de Sociedad de laInformación a las circunstancias cambian-tes de cada momento y la coordinación téc-nica del proyecto transversal gnuLinEx (soft-ware libre).

El software libre gnuLinEx, auténtico ele-mento vertebrador de la Estrategia Globalde S.I. de Extremadura, proporciona unaplataforma segura, fiable, libre de virus, y decódigo abierto, a la Red Tecnológica Educa-tiva, al sistema sanitario extremeño (proyec-to JARA), y a las dependencias administra-tivas de la Junta de Extremadura.

Dicho software es ya una realidad en elSistema Educativo, donde ha demostradosu solidez en situaciones críticas como lamigración de versión de gnuLinEx de unos45.000 ordenadores en un mes sin proble-mas reseñables. Y se constata una ausenciatotal y absoluta de virus informáticos, lo quemejora objetivamente la productividad y larentabilidad tanto de la instalación como delos recursos humanos dedicados al manteni-miento.

En las bibliotecas públicas de Extremadura,dependientes de la Consejería de Cultura,también se ha iniciado ya el proceso deinstalación de GnuLinEx.

En estos momentos, se puede constatar quegnuLinEx está siendo utilizado por aproxi-madamente 2.500 funcionarios públicos dela Junta de Extremadura, excluidos docen-tes, y hay departamentos donde sus previsio-nes son aumentar su integración. Todo,enmarcado en el Plan de Modernización,Simplificación y Calidad para la Adminis-tración de la Comunidad Autónoma deExtremadura (2004-2007). Son datos quehablan por sí mismos.

Del mismo modo, son varias las Consejeríasque han implantado hace tiempo serviciosde gestión interna con servidores basados engnuLinEx.

En el ámbito privado, los integradores deordenadores y mayoristas de hardware de laregión, colaboran ofreciendo máquinas yperiféricos compatibles con gnuLinEx.

Por último, cabe destacar que varios de losmás grandes fabricantes de hardware man-tienen contactos con la Junta de Extremadurao han firmado ya convenios de colabora-ción: Oki, Kyoscera, El Corte Inglés,Intel,...etc.

En este contexto es en el que hay que enten-der el acuerdo del Consejo de Gobierno del25 de julio ya mencionado: la integración y

Formatos estándares abiertosy software libre en la Administración

Pública de Extremadura

Luis Millán Vázquez de MiguelConsejero de Infraestructuras y DesarrolloTecnológico, Junta de Extremadura

<consejero.idt@juntaextremadura.net><consejero.idt@juntaextremadura.net><consejero.idt@juntaextremadura.net><consejero.idt@juntaextremadura.net><consejero.idt@juntaextremadura.net>

Resumen: el acuerdo del Consejo de Gobierno de la Junta de Extremadura de 25 de julio de2006, estableció los formatos OASIS ODF y el PDF/A como los formatos oficiales dentro de laAdministración Pública. Este hecho, de gran repercusión en medios nacionales y extranjeros,entronca y encuentra sentido en una estrategia global de Sociedad de la Información y del Cono-cimiento, que tiene su máximo protagonismo en la distribución de software libre gnuLinEx, exis-tiendo aplicaciones de la misma a diferentes ámbitos; razón por la cual, como parte del mismoacuerdo relativo a los formatos se ha establecido la migración a software libre de todos los PC’sde la Junta de Extremadura en el plazo máximo de un año.

Palabras clave: estándares abiertos, gnuLinex, interoperabilidad, Junta de Extremadura, OpenDocument.

Autor

Luis Millán Vázquez de Miguel es Licenciado en Ciencias Químicas y Doctor en Ciencias con PremioExtraordinario de Doctorado. Es Profesor Titular de Química Orgánica en la Universidad de Extremadura.Desde 1985 a 1987 fue becario e investigador en la University of Florida (Gainesville, EE.UU.). EsMiembro del Comité Federal del Partido Socialista Obrero Español y desde enero de 2003 es el coordi-nador de la Sectorial sobre la Sociedad de la Información. Desde su creación en 1995 hasta la actualidades Presidente de la Junta Rectora de FUNDECYT (Fundación para el Desarrollo de la Ciencia y la Tecno-logía en Extremadura). En el Gobierno de Extremadura desarrolla distintas tareas, aunque todas relacio-nadas con la educación. En 1995 es nombrado Consejero de Educación y Juventud hasta 1999, y hasido Consejero de Educación, Ciencia y Tecnología desde 1999 hasta ahora.

novática nº 184 noviembre-diciembre 2006 45

Formato de Documento Abierto (ODF) monografía

monografía

extensión de la Sociedad de la Informaciónen Extremadura hacía necesario dar un pasomás: arbitrar las medidas oportunas paragarantizar la interconexión entre las distin-tas actuaciones.

¿Cuál era el elemento común? Los ciudada-nos, usuarios siempre de la tecnología, comoalumno, sanitario, jubilado,... y usuariosconstantes de la Administración Pública.Había que impulsar la permeabilidad de losdatos, de la información entre los distintosdepartamentos de la Junta de Extremadura,las entidades provinciales, locales, y los ciu-dadanos. Y aquí es donde resulta ventajosohaber sido de los primeros. Nuestra expe-riencia nos mostraba a todas luces que paralograr una interoperabilidad real, garanti-zando la validez de los formatos de datos enel tiempo, sólo hay un medio: utilizarestándares. Y que sean abiertos. De ese modologramos, además, el acercamiento cómodoy eficaz a los ciudadanos, que no tendránque comprar ningún tipo de programainformático para relacionarse con la Admi-nistración Pública.

Precisamente la Junta de Extremadura hadado carácter oficial a los formatos de losarchivos informáticos más extendidos, alafirmar que la información electrónica gene-rada y de intercambio en los distintos órga-nos que estructuran la Junta de Extremadurautilizarán obligatoriamente uno de losformatos estándar de almacenamiento deinformación siguientes:

Formato de Documento Abierto paraAplicaciones Ofimáticas (OASIS OpenDocument Format, sobre la norma ISO/IECDIS 26300), para información en elabora-ción y proceso administrativo.

Formato de Documento de IntercambioPDF/A (Portable Document Format ISO19005-1:2005), para información de la quese desea garantizar su inalterabilidad de vi-sualización.

Coherente con lo anterior, en la Administra-ción Pública de Extremadura se establecencomo herramientas informáticas de produc-tividad personal para todos los empleadospúblicos de la Junta de Extremadura lasimplementaciones ofimáticas que soportenobligatoriamente en modo nativo losestándares establecidos en el punto primeroy que serán inventariadas en el marco de laCOMTIC (comisión interdepartamental decoordinación en asuntos informáticos), pro-poniéndose su implantación inmediata so-bre los puestos de trabajo de los empleadospúblicos de la Junta de Extremadura.

Queda claro, a tenor de lo expuesto hasta elmomento, que para avanzar en la integra-ción de la Sociedad de la Información en laAdministración Pública moderna y en unasociedad global, hay que garantizar el con-

trol y gestión de aspectos tan trascendentescomo independencia tecnológica,interoperabilidad entre plataformasinformáticas, homogeneidad de los sistemasde información, seguridad informática enmateria de sistemas de información, innova-ción tecnológica real y cumplimiento deestándares informáticos abiertos y libres.

Está demostrado que las consideracionesanteriores sólo se pueden lograr consolidan-do una plataforma de sistemas y aplicacio-nes informáticas estándares y libres.

En este marco, y dado que todos los puestosde la administración acabarán funcionandocon OpenOffice 2.0 como paquete ofimático,pues se ajusta brillantemente a los estándaresadoptados por la Junta de Extremadura, secontempla también el que los aspirantes queparticipen en los diferentes procesos de se-lección para la provisión de puestos de tra-bajo vacantes de los distintos cuerpos/cate-gorías del personal de la administración denuestra Comunidad Autónoma, utilicenOpenOffice 2.0, sustituyendo de esta formael software propietario que hasta ahora seexigía en las distintas convocatorias.

Por último, cabe destacar que Extremadura,a pesar de ser pionera, sí conocía referenciasimportantísimas que avalaban su apuestapor los estándares abiertos dentro de la Ad-ministración: La Propuesta de recomendaciones a la

Administración General del Estado sobreutilización del software libre y de fuentesabiertas ha sido elaborada por el Grupo desoftware libre en la Administración Generaldel Estado, creado por el Consejo Superiorde Informática y para el Impulso de la Admi-nistración Electrónica con el mandato deformular un conjunto de recomendacionesrelativas a la utilización del software libre yde fuentes abiertas por la AdministraciónGeneral del Estado. Este grupo de trabajo locoordina precisamente la Junta deExtremadura. La Propuesta de Recomendaciones fue

adoptada por el Consejo Superior de Infor-mática y para el Impulso de la Administra-ción Electrónica de 19 de mayo de 2005, elComité Sectorial de Administración Elec-trónica (AGE- CCAA) de 11 de mayo de2005 y el Pleno de CIABSI de 21 de abril de2005.

Estas recomendaciones persiguen optimizaral aprovisionamiento, desarrollo, manteni-miento y explotación del software, así comola libertad de elección, la protección de lainversión, el control precio/rendimiento y lainteroperabilidad, a la vez de asegurar laindependencia tecnológica de la Adminis-tración frente a proveedores concretos.

En el ámbito europeo, además de iniciativas

particulares, pero de gran peso específicopor sus protagonistas, como puede ser lamigración a software libre iniciada por elAyuntamiento de Munich (Alemania), cabedestacar que son numerosos los estudiosque se vienen realizando en los últimos cua-tro años orientados bien a explicar de unaforma exhaustiva el software libre y losformatos estándares abiertos y a explorar losproductos disponibles, o bien orientados aobtener datos cuantitativos de su grado deutilización o difusión en diversos ámbitos,tanto del sector público como del sectorprivado. Entre ellos podemos destacar:

Las Directrices IDA (Interchange of Databetween Administrations) de migración asoftware de fuentes abiertas son un productodel Programa comunitario IDA dirigido alos gestores y profesionales de tecnologíasde la información de las AdministracionesPúblicas con el objetivo de ayudar a decidirsi se debe emprender la migración a softwarede fuentes abiertas y de describir cómo de-biera llevarse adelante, en su caso, la citadamigración.

El Estudio del Programa IDA sobre eluso de los programas de fuentes abiertas enel Sector Público analiza diversos aspectosrelativos a la utilización del software de fuen-tes abiertas por las Administraciones Públi-cas.

El Marco Europeo de Interoperabilidaddefine un conjunto de recomendaciones ydirectrices para los servicios de administra-ción electrónica.

novática nº 184 noviembre-diciembre 200646

secciones técnicas Enseñanza Universitaria de la Informática

secciones técnicas

1. IntroducciónLa actividad docente del profesorado deenseñanzas técnicas se encuentra condicio-nada por la necesidad de renovación cons-tante de conocimientos. También debemostener en cuenta el marco dibujado por elEspacio Europeo de Enseñanza Superior(EEES) y las agencias y procedimientos deacreditación de titulaciones y centros.

En este marco, la mejora en la docencia delas titulaciones técnicas es compartida portodos los agentes implicados en la misma.Aunque socialmente se reconoce la buenaformación de los titulados tanto en conoci-mientos como en aptitudes para abordar conéxito el desarrollo de su posterior carreraprofesional, desde diversos ámbitos, tantoexternos como internos a la universidad, secuestiona el esfuerzo empleado por el estu-diante para graduarse. Pongamos, comoejemplo, el tiempo de duración media deestudios de ingeniería técnica y de ingenie-ría, 5,7 y 7,6 años respectivamente [1].

Ante esta situación, la Escuela UniversitariaPolitécnica de Teruel (en adelante la EUPT)ha desarrollado una serie de acciones, algu-na de ellas descritas en el presente trabajo,teniendo en mente la mejora del proceso deaprendizaje de alumnos y como consecuen-cia, la mejora de indicadores, fundamental-mente la tasa de rendimiento y la tasa deéxito [1].

2. Contexto del centroLa Escuela Universitaria Politécnica deTeruel nace a principios de los noventa ysurge en el proceso de expansión universita-ria español, ligado a factores demográficos ysociales. Es un centro propio de la Universi-dad de Zaragoza y con las sedes departa-mentales en la ciudad de Zaragoza. Inicial-mente cuenta con una única titulación yespecialidad, Ingeniería Técnica en Teleco-municación, Sistemas Electrónicos (ITTSE).Posteriormente se incorpora la titulación deIngeniería Técnica en Informática de Ges-tión (ITIG).

Acciones y reacciones en el caminode la mejora docente universitaria

Alfonso Blesa Gascón1, PabloBueso Franc2, Carlos CatalánCantero3, Raquel LacuestaGilaberte3, Mariano UbéSanjuán4

1Dpto. Ingeniería Electrónica y Comunica-ciones, 2Dpto. de Ciencia y Tecnología deMateriales y Fluidos, 3Dpto. de Informáticae Ingeniería de Sistemas, 4Dpto. de Econo-mía y Dirección de Empresas, Escuela Uni-versitaria Politécnica de Teruel, Universidadde Zaragoza

{ablesa, pbuesof, ccatalan, lacuesta, mube}@unizar.es{ablesa, pbuesof, ccatalan, lacuesta, mube}@unizar.es{ablesa, pbuesof, ccatalan, lacuesta, mube}@unizar.es{ablesa, pbuesof, ccatalan, lacuesta, mube}@unizar.es{ablesa, pbuesof, ccatalan, lacuesta, mube}@unizar.es

Este artículo fue seleccionado para su publicación en Novática Novática Novática Novática Novática entre las ponencias presentadas a JENUI2005 (XI Jornadas de Enseñanza Universitaria de la Informática), evento celebrado en Villaviciosa deOdón (Madrid) y del que ATI fue entidad colaboradora.

Resumen: en este trabajo se presentan diversas acciones, realizadas durante varios años, encamina-das a la mejora de los resultados docentes de una escuela universitaria politécnica que imparte inge-nierías técnicas del ámbito de las TIC. Inicialmente se describe el contexto del centro indicando losprincipales datos de relevancia. A continuación se relatan las acciones llevadas a cabo y se muestranlos resultados obtenidos en relación a la mejora de los parámetros de rendimiento académico. Final-mente se indican las perspectivas de futuro enmarcadas en el proceso de adaptación a Bolonia y ladisminución del número de estudiantes.

Palabras clave: adaptación al EEES, mejora docente, plan estratégico, programa de tutorización.

Además actualmente se imparten dos diplo-mas de especialización, como títulos pro-pios de la Universidad, en el ámbito de lasTIC. El hecho de situar un centro de este tipoen una ciudad pequeña intenta satisfaceruna demanda mediante el compromiso delgobierno regional de llevar estudios univer-sitarios a diferentes puntos del territorio [2].El centro se ubica en un campus periférico dela Universidad de Zaragoza, donde desdebastantes años antes ya existen estudios uni-versitarios en el campo de las ciencias socia-les y humanísticas.

2.1. AlumnadoLas cifras de alumnos reflejan una tendenciaanáloga a la existente en algunas titulacionesde la universidad española. En la tabla 1tabla 1tabla 1tabla 1tabla 1pueden observarse los números de alumnado.

La disminución en el número de alumnos esdebida a varios factores. Aunque indudable-mente el factor demográfico es el más impor-tante, también el aumento significativo decentros creados impartiendo la misma titu-lación ha influido. Quizá pueda existir, comoindican algunos [11], un nuevo factor: ladisminución en la demanda de las carrerascientífico-técnicas. Como dato orientativo,de diecisiete centros que imparten bachille-rato en la provincia, únicamente tres impar-ten la modalidad de bachillerato tecnológi-co, y de estos sólo uno está en la capital.Respecto de las características de nuestroalumnado en el centro, es interesante cono-cer las notas de acceso a la universidad,detalladas en la fffffigura 1gura 1gura 1gura 1gura 1.

Observamos que las notas no son demasia-do altas; una razón puede ser que los alum-nos más brillantes tal vez se orienten haciacarreras de estudios superiores si existe dis-ponibilidad para hacerlo. En cualquier casoes una cuestión a tener en cuenta, sobre todosi nuestros estudios tienen un nivel de exi-

gencia elevado [7]. También es importanteel grado de motivación hacia los estudios: enencuestas realizadas a los nuevos alumnosse comprueba que en más de un 70% de loscasos, la razón de elegir nuestras titulacioneses simplemente el hecho de residir en laciudad o en su entorno más cercano.

Una de las razones cruciales que puedenmotivar la disminución de alumnos entitulaciones técnicas es la dificultad de losestudios, indicada por un dato clave, el nú-mero de años que se tarda en acabar es casiel doble de lo que marcan los planes deestudios [1] [11]. Se puede argumentar queel nivel de entrada de nuestros alumnos esbajo, especialmente en materias como mate-máticas, ver informe PISA [9], o que nues-tros alumnos no tienen la cultura del esfuer-zo [10], pero pensamos que eso en ocasioneses utilizado como disculpa para descargarsede responsabilidad y no revisar nuestra ac-tuación docente.

Otro factor a tener en cuenta es la políticaeducativa española de las últimas dos déca-das. En España los estudios de FormaciónProfesional y equivalentes han estado muydevaluados frente a los estudios universita-rios, a diferencia de otros países de nuestroentorno (Francia, Alemania, etc.) [2]. Esto

ITTSE ITIG 1999/2000 396 77 2000/2001 388 126 2001/2002 360 148 2002/2003 321 163 2003/2004 280 159 2004/2005 213 167

Tabla 1. Alumnos por titulación (Fuente:Universidad de Zaragoza).

novática nº 184 noviembre-diciembre 2006 47

Enseñanza Universitaria de la Informática secciones técnicas

secciones técnicas

Figura 1. Notas de acceso de los alumnos a la ITIG y a la EUPT (Fuente: Universidad de Zaragoza).

ha llevado a que los alumnos en la universi-dad tripliquen el número de alumnos en losestudios de tipo profesional [8]. Parece, sinembargo, que esta situación está empezandoa cambiar si observamos el incremento cons-tante en las cifras de matriculados de losciclos de formación de grado superior, frenteal descenso universitario [8]. En concreto ennuestra Universidad este descenso ha sido deun 20% desde el curso 1994/1995 [12].

En cualquier caso pensamos que deben rea-lizarse acciones encaminadas a paliar enparte el descenso de alumnado, especial-mente en los centros pequeños, más sensi-bles a dicho descenso. Estas acciones pue-den ser variadas, pero quizá la más impor-tante sea mejorar la calidad de la docenciaimpartida. El menor número de alumnosdebe ser en este caso un factor favorable, yaque al desaparecer el problema de lamasificación es posible una mejor utiliza-ción de los recursos existentes.

2.2. ProfesoradoSin duda un aspecto importante es la situa-ción del profesorado. El centro en el mo-mento de su creación estaba inmerso en lapolítica de "coste cero" con la que se crearonmuchos otros centros en las universidadesespañolas. Esto se tradujo en la contrataciónde profesorado joven y en proceso de forma-ción, asignándole aún así plenas responsa-bilidades docentes [2]. En la tabla 2tabla 2tabla 2tabla 2tabla 2 semuestra la evolución del profesorado.

Todos los titulares están incluidos en lacategoría de Profesor Titular de EscuelaUniversitaria. En cuanto a su formación, elnúmero actual de doctores se va incremen-tando todos los años, ya que los profesoresque no lo son están en proceso de elabora-ción de su tesis doctoral.

Hay que destacar que una dificultad añadidaen la formación del profesorado es el hechode estar en un campus periférico alejado delas sedes departamentales. Así, el profesora-do tiene que asumir los costes de tiempo derealizar sus estudios de doctorado en elcampus central, donde están la mayoría delas sedes departamentales. La integración engrupos de investigación consolidados tam-bién se ve dificultada. No cabe duda que esteproceso de formación, obstaculizado por elfactor distancia, puede repercutir en la cali-dad de la docencia.

2.3. Resultados académicos curso1999/2000En este contexto presentamos los resultadosacadémicos del centro en el curso 1999/2000. El objetivo es poder comparar con losresultados actuales y así confirmar el efectopositivo de las acciones llevadas a cabo. Losindicadores utilizados en cada curso paramedir el rendimiento son los siguientes [1]:

Tasa de rendimiento, entendida como larelación entre los créditos superados respec-to de los matriculados.

Tasa de éxito, entendida como la relaciónentre los créditos superados respecto de lospresentados a examen.

En la tabla 3 tabla 3 tabla 3 tabla 3 tabla 3 podemos ver estas tasas deforma comparativa frente a la macro-área ya la propia universidad. Por macro-área téc-nica se entiende el conjunto de titulacionesque se imparten en las Escuelas de Ingenie-ría de la Universidad de Zaragoza.

Los valores muestran que los resultados delcentro no eran satisfactorios en ese momen-to; es especialmente reveladora la tasa derendimiento, que indica que el número dealumnos que se presentaban a los exámenesen ese curso era muy bajo.

Ante esta situación se empieza a pensar en eldiseño de posibles acciones que mejoren demanera significativa estos resultados. Elobjeto del presente trabajo es exponer dichasacciones mostrando la preocupación colec-tiva hacia tal escenario, como muestra derespuesta activa. El diseño de las acciones serealiza y se lleva a término desde la Direccióny la Comisión de Docencia, persiguiendocontar con el consenso de todos los miem-bros del centro.

3. Acciones para la mejora docentePara que la formación sea adecuada a lasexpectativas existentes en la sociedad dondevan a ejercer su labor profesional nuestrostitulados, la docencia no puede anclarse enel pasado, más si cabe en el caso de unosestudios que se encuentran en constanteproceso de avance, como es el caso de lastecnologías de la información y comunica-ción. De este modo, el centro es lugar deactuación de ciertas acciones de mejora do-cente, las principales de las cuales serán lasque aquí comentemos brevemente.

3.1. Jornadas de DocenciaLa inquietud por mejorar la calidad de ladocencia hace surgir la necesidad de un forode debate en el que se puedan debatir temasrelacionados con la misma. La Comisión deDocencia, haciéndose eco de esta preocupa-ción, organiza unas jornadas para la discu-sión conjunta de estos temas.

En las primeras Jornadas de Docencia, de-sarrolladas en una primera fase en septiem-bre de 1999 y en una segunda fase en juniode 2000, se abordó la relación entre las

Titulares No

titulares

A tiempo parcial

TOTAL

1999/2000 10 14 4 24 2000/2001 14 16 4 30 2001/2002 14 18 5 32 2002/2003 20 16 6 36 2003/2004 20 17 7 37 2004/2005 20 17 9 37

Tabla 2. Evolución del profesorado en la EUPT. (Fuente: Universidad de Zaragoza).

novática nº 184 noviembre-diciembre 200648

secciones técnicas Enseñanza Universitaria de la Informática

secciones técnicas

diferentes asignaturas de Ingeniería Técnicaen Telecomunicación. En aquellos días no seplanteó la titulación de Informática de Ges-tión, pues la misma se encontraba en suprimer año de impartición y todavía se care-cía de experiencia práctica en la misma, peroconsideramos de interés la mención de estasjornadas como muestra del espíritu de mejo-ra totalmente exportable al caso informático.El formato de las jornadas contó con sesio-nes donde cada docente exponía brevementeante los demás los aspectos específicos de suasignatura. Un objetivo era el aumentar elgrado de conocimiento que los profesorestenían de la titulación, en algunos casos nodemasiado elevado al tener procedencia di-versa. Otros objetivos eran tratar aspectoscomo coherencia entre evaluación y trabajoen clase, solapes de contenidos entre asigna-turas, tipos de prácticas, etc. Posteriormentese contó con conferencias de expertos enciencias de la educación y la profesión. Elresultado de estas primeras jornadas sirviópara coordinar los contenidos entre asigna-turas, y comenzar el proceso de reflexiónsobre la labor docente.

En octubre de 2001 la Comisión de Docen-cia auspicia las segundas jornadas, cuyoobjetivo fundamentalmente fue abordar lafigura del tutor del alumno y la decisiónsobre su implantación en las dos titulaciones,acción que relatamos más adelante con unmayor detenimiento.

Finalmente, durante los meses de septiem-bre, octubre y noviembre de 2002 acontecie-ron las terceras jornadas, centradas en laevaluación. Se realizaron también reunionesentre profesores y conferencias de expertos.En las primeras sesiones todos y cada uno delos profesores exponían al resto el caso de suasignatura en lo relativo a los criterios ymétodos de evaluación. A estas sesionessiguieron sesiones de debate abierto. Lasprincipales conclusiones fueron un impulsoa la evaluación continua y la creación de unequipo de coordinadores en varios niveles:coordinador de titulación, coordinador decurso y coordinador de grupo de materiasafines. La tarea de estos coordinadores esfundamentalmente identificar problemas yproponer soluciones en su ámbito. El pasode un sistema de evaluación por exámenesfinales a una evaluación continua, en mu-chos casos por trabajos, tiene un peligro: nomedir bien la carga del trabajo del alumno.

Esto repercute en los rendimientos, incre-mento en el abandono de asignaturas, etc.Así, como resultado de estas jornadas, serealizaron reuniones entre profesores de unmismo curso, para determinar, y poner encomún, las horas de trabajo necesarias encada asignatura. También se realizaron en-cuestas a los alumnos sobre el mismo tema.Igualmente se solicitó a la Delegación deAlumnos que elaborara un documento contodas aquellas cuestiones relativas a la mejo-ra de la docencia en el centro. Todo ello haservido para que se revisen y adecuen losprogramas y cargas de trabajo de las asigna-turas. Este esfuerzo se podrá aprovechar enel futuro cálculo de créditos ECTS (EuropeanCredit Transfer System).

3.2. Programa de TutorizaciónEn el segundo cuatrimestre del curso 1999-2000, como respuesta natural del grupo dedocentes en asignaturas del primer cuatri-mestre de primer curso de Informática deGestión y ante los malos resultados acadé-micos se puso en marcha un plan detutorización parcial.

En su momento esta acción fue novedosa en laUniversidad de Zaragoza, actualmente ya hayun plan de implantación conjunta en toda launiversidad, en aquellos centros que volunta-riamente así lo decidan, con el apoyo del Insti-tuto de Ciencias de la Educación de la Univer-sidad. Las tareas que realizan estos tutoresson: ayuda al alumno en problemas de organi-zación, integración en el centro y la universi-dad, técnicas de estudio y motivación.

Para su puesta en marcha se organizaronvarias reuniones al efecto, a las que asistie-ron profesores y miembros de la Delegaciónde Alumnos, llegándose a una serie de con-clusiones, a partir de las cuales se articuló elPrograma de Tutorización del centro. Así seestablecía la pertenencia voluntaria al pro-grama, tanto por parte de profesores comode alumnos, la conveniencia de que losdocentes tutores recibieran preparación es-pecífica y la de considerar como principalesdestinatarios a los alumnos de primer ingre-so en el centro, seguidos por alumnos deprimero repetidores y, según la disponibili-dad de tutores, el resto del alumnado. Resal-tar que más de la mitad de los profesores sontutores en la actualidad. También es impor-tante reseñar la favorable acogida de estainiciativa desde los Vicerrectorados de Or-

denación Académica y de Estudiantes denuestra Universidad.

3.3. Organización de conferencias ycursosComo un elemento de formación de la acti-vidad docente del profesorado y de la activi-dad de aprendizaje del alumno, se vienenimpartiendo por profesionales externos di-versas conferencias, seminarios o cursos,mesas redondas, enmarcados en distintosactos, todos ellos con un componente demejora a la docencia. En el capítulo másimportante, el de cursos, coordinado con elInstituto de Ciencias de la Educación (ICE)de nuestra universidad, entre otros citamos:

Metodologías activas en el ámbito univer-sitario. Trabajo en equipo.

Innovación docente: metodologías del casoy aprendizaje basado en problemas.

El diseño del proyecto de innovación do-cente en ingeniería.

Técnicas de trabajo intelectual.Plan de acción tutorial y Taller de forma-

ción de tutores.Diseño de programas desde la perspectiva

ECTS.Taller de comunicación interpersonal.El proceso de aprendizaje-enseñanza por

competencias.

Algunos de estos cursos se han impartidotambién a los alumnos, y en este momento seestá pendiente de una propuesta del ICEpara ofrecer a éstos un programa de cursoscompleto. Con este fin se han habilitadohuecos en los horarios de clases, de maneraque cursos relativos a materias no específi-cas de la titulación se integren como unaactividad más del alumno.

3.4. Plan Estratégico del centroEn consonancia con el Plan Estratégico denuestra universidad, se procedió a elaborarel Plan Estratégico de centro entre noviem-bre de 2002 y marzo de 2003 [6]. Para ello,se solicitó la colaboración de aquellos miem-bros de la comunidad universitaria adscritosal centro que lo considerasen oportuno. Seformó un equipo de personas, entre miem-bros del equipo directivo, profesores, alum-nos, personal de administración y servicios ycolaboradores externos, para así poder con-tar con opiniones provenientes de variossectores, incluyendo también personas aje-nas a la institución.

Este equipo se reunió en varias series desesiones de trabajo, identificando debilida-des, amenazas, fortalezas y oportunidadesrelativas a las siguientes áreas temáticas:docencia, investigación, gestión interna yrelaciones exteriores. Seguidamente, y paracada área, se marcaron objetivos y con ellosestrategias tendentes a su consecución. Cadaestrategia se desarrolló con acciones concre-tas, responsables e indicadores; todo ello

Tabla 3. Tasas de rendimiento curso 1999/2000 (Fuente: Universidad de Zaragoza).

Tasa rendimiento Tasa éxito Centro 0,377 0,700

Macro-área técnica 0,498 0,763 Universidad 0,593 0,822

novática nº 184 noviembre-diciembre 2006 49

Enseñanza Universitaria de la Informática secciones técnicas

secciones técnicas

delimitado en un horizonte temporal con-creto. Aprobado en sesión extraordinaria deJunta de Centro en marzo de 2003, el PlanEstratégico ha supuesto una sistematiza-ción de aquellas acciones que el centro hacreído oportunas, encaminadas, entre otraslíneas, a mejorar la docencia impartida alalumno, en diversos aspectos. Las principa-les líneas de acción establecidas por el PlanEstratégico en lo relativo a docencia son:

Mejora y consolidación del Plan Tutor.Utilización de las herramientas de nuestra

universidad para el uso de tecnologías Web.Plan de Evaluación Curricular.Designación de coordinadores docentes.Bolsas de viaje para realización del doc-

torado y adecuación de horarios.Participación en convocatorias de inno-

vación docente de nuestra universidad.

4. Resultados actualesProcede ahora mostrar y analizar el resulta-do de las acciones realizadas. En la tabla 4 tabla 4 tabla 4 tabla 4 tabla 4indicamos los resultados del último cursodel que se dispone de datos completos, mien-tras que en las figuras 2 y 3 figuras 2 y 3 figuras 2 y 3 figuras 2 y 3 figuras 2 y 3 mostramos lasgráficas de evolución de las tasas. Se observaque la evolución es claramente positiva entodos los casos.

En la tasa de rendimiento vemos que sesupera al indicador de la macro-área, aun-que se permanece por debajo del indicadorde la universidad. En lo relativo a la tasa deéxito se supera de forma clara a la macro-área y se equipara prácticamente a los valo-res de la universidad.

Pensamos que esta mejora ha sido influida porlas acciones indicadas en los apartados ante-riores, que han derivado principalmente en:

Paso a un sistema de evaluación conti-nua, promoviendo un esfuerzo más conti-nuado por parte del alumno.

Ajuste de las cargas de trabajo de lasasignaturas, que en algunos casos estabansobredimensionadas.

Adecuación entre el nivel impartido enclase y el exigido en las pruebas de evalua-ción, lo que no implica que ese nivel hayadisminuido.

Facilitar a los alumnos su paso por launiversidad mediante un tutor personal.Queremos hacer constar que además de losresultados concretos, las acciones han servi-do para hacer ver a la mayoría del profesora-do del centro la importancia de revisar, ac-tualizar y mejorar de manera continua lalabor docente. Esto ha sido en gran parte

favorecido por la juventud de un profesora-do abierto a no repetir los, no siempre bue-nos, métodos docentes recibidos.

5. Perspectiva futuraLa perspectiva futura debe enmarcarse in-dudablemente en el proceso de adaptaciónal Espacio Europeo de Educación Superior(EEES) y en un reducido número de alum-nos. Respecto del primer aspecto, en estosmomentos el objetivo del centro es impartirlos títulos de grado en cuanto esté disponibleel catálogo de titulaciones, y a medio plazoimpartir los respectivos niveles de postgrado.

Pero la adaptación al nuevo marco europeono es sólo la modificación de los títulosimpartidos, y la mejora de las tasas de rendi-miento, es también la adopción de métodosdocentes, más centrados en el aprendizaje,con el fin de lograr el objetivo de que nues-tros alumnos "aprendan a aprender" [7]. Eneste sentido en el centro se vienen desarro-llando algunas iniciativas amparadas en con-vocatorias de innovación docente de nuestrauniversidad [6] [3] que deben permitir eva-luar dichos métodos docentes. Es importan-te incidir en el esfuerzo en formación deprofesorado que debe hacerse.

Por otro lado, otra de las estrategias que elcentro se propone es estudiar impartir losestudios actuales a través de métodos no-presenciales o semi-presenciales. Dentro deeste ámbito la Universidad de Zaragoza po-tencia la utilización de campus virtuales

mediante el ADD (Anillo Digital Docente),utilizando la herramienta WebCT [13]. Ac-tualmente, un número elevado de profesoresdel centro utiliza dicha herramienta comocomplemento a sus clases.

WebCT es una herramienta Web que permitela creación y organización de materiales do-centes en distintos formatos, dispone de variasformas de comunicación entre el profesor y elalumno: correo electrónico, foros, chat o piza-rra compartida; también dispone de herra-mientas de evaluación y trabajo en grupo: test,exámenes, trabajos... y de utilidades de apoyoal estudio para el estudiante, así como deutilidades apoyo de gestión al profesor, talescomo configuración de listas, control de acce-so, etc.

Dichas herramientas son accesibles únicamentea los alumnos matriculados en la asignatura.De todas las opciones, las más usadas son lasde creación y organización de materiales do-centes. El resto, se van integrando poco a poco,a medida que el profesorado se conciencia delos beneficios de su utilización. Quizás seanestas herramientas las que permitan introducirnuevas posibilidades en centros universitarios.En general cada vez se demuestra más interésno sólo en dichas herramientas sino en lainnovación docente que pueden introducir di-chas herramientas tecnológicas [4].

6. ConclusionesEn este trabajo se han presentado diversasacciones encaminadas a mejorar el rendi-miento docente, en el contexto de una escue-la universitaria que imparte titulaciones deingeniería técnicas del ámbito de las TIC.Los resultados obtenidos muestran que di-chas acciones han influido en la mejora.Como conclusiones concretas podemos in-dicar:

Se ha producido una concienciación ac-

Tasa rendimiento Tasa éxito Centro 0,530 0,824

Macro-área 0,511 0,773 Universidad 0,579 0,826

Tabla 4. Tasas de rendimiento curso 2002/2003 (Fuente: Universidad de Zaragoza).

Figura 2. Evolución de las tasas de rendimiento.

novática nº 184 noviembre-diciembre 200650

secciones técnicas Enseñanza Universitaria de la Informática

secciones técnicas

tiva por parte del centro ante un escenariomarcado por la disminución del alumnado yunos rendimientos académicos mejorables.

Dicha concienciación se ha traducido enuna serie de acciones, con carácter estructu-ral y no puntual.

Existe una incertidumbre a fecha de hoy enlo que respecta al proceso de convergencia alEspacio Europeo de Educación Superior,compartida con la inmensa mayoría de lacomunidad universitaria. Entendemos quela adaptación a dicho espacio es una oportu-nidad para mejorar. Para acabar nos pareceimportante resaltar que todas las accionesllevadas a cabo han contado con el apoyo denuestra universidad.

Figura 3. Evolución de las tasas de éxito.

Referencias

[1] J.Bara, J.F. Córdoba, R. De Luis, J.H. Marco,P.M. Castro. Informe Transversal del RendimientoAcadémico de las Ingenierías Técnicas. Plan Na-cional de Evaluación de la Calidad de las Universi-dades. Consejo de Universidades, febrero 2001.[2] Cátedra UNESCO de Gestión y Política Uni-versitaria. Libro Blanco sobre la descentralizacióny estructura organizativa del Sistema Universitariode Aragón. Departamento de Educación y Ciencia.Gobierno de Aragón, 2001.[3] Convocatoria de acciones de innovación ymejora de la docencia. Proyecto de innovacióndocente multidisciplinar en el diseño de productoselectrónicos. Vicerrectorado de Ordenación Aca-démica. Universidad de Zaragoza. 2004.

[4] M. Área. Creación y uso de Web para ladocencia universitaria. Guía didáctica. Departa-mento de Didáctica e Investigación Educativa y delComportamiento, Facultad de Educación. Univer-sidad de la Laguna, 2003.[5] Joint declaration of the European Ministers ofEducation. The European Higher Education Area,The European Space for Higher Education, Bologna,June 1999.[6] R. Lacuesta, C. Catalán. Aprendizaje Basadoen Problemas: Una experiencia interdisciplinar enIngeniería Técnica en Informática de Gestión, Ac-tas de las Jornadas de Enseñanza Universitaria dela Informática (JENUI), Alicante, pp. 305-311, julio2004.[7] J. Mas, J.M. Valiente, L. Zúnica, R. Alcocer,J.V. Benlloch, P. Blesa. Estudio de la influenciasobre el rendimiento académico de la nota deacceso y procedencia (COU/FP) en la E.U. deInformática. Actas de las Jornadas de EnseñanzaUniversitaria de la Informática (JENUI), Cáceres,pp. 197-204, julio 2002.[8] Ministerio de Educación, Cultura y Deporte.Datos Básicos de la Educación en España en elcurso 2004/2005.[9] Ministerio de Educación, Cultura y Deporte.Evaluación PISA 2003. Resumen de los primerosresultados en España, diciembre 2004.[10] N. Pavón. ¿Están los alumnos preparadospara el Tour de Francia? Comportamientos, hábi-tos y Sistema de Créditos Europeo. Actas de las XJornadas de Enseñanza Universitaria de la Infor-mática (JENUI), Alicante, pp. 39-46, julio 2004.[11] B. Suárez. Las Enseñanzas Técnicas y elEspacio Europeo de Educación Superior. Jornadasobre Convergencia en el Espacio Europeo deEducación Superior, septiembre 2002, Zaragoza.[12] Universidad de Zaragoza. Evolución alum-nos matriculados desde el curso 1994/1995<www.unizar.es/servicios/primer/6estadisticas/estadisticas.html>.[13] Universidad de Zaragoza. Anillo Digital Do-cente. <http://add.unizar.es/start/add.html>.

novática nº 184 noviembre-diciembre 2006 51

Informática Gráfica secciones técnicas

secciones técnicas

1. IntroducciónNo cabe duda que la mayor parte de las aplica-ciones gráficas se desarrollan, o han sido desa-rrolladas, utilizando principalmente el lengua-je de programación C/C++. Esto se debe aque las principales bibliotecas para la creaciónde aplicaciones gráficas (OpenGL y DirectX)se han desarrollado utilizando principalmenteestos lenguajes de programación.

Durante mucho tiempo se ha mantenido elprejuicio de que Java es un lenguaje de pro-gramación lento en la ejecución porque esinterpretado. Nada más lejos de la realidad.Desde sus inicios, acercar la velocidad deejecución del Java a otros lenguajes de pro-gramación que podríamos llamar clásicos,como C/C++ y Fortran, ha sido uno de losprincipales objetivos de sus desarrolladores.Tal es así que en la actualidad existen testque muestran que el rendimiento de Java seacerca al de C/C++ o Fortran.

En la actualidad es posible programarOpenGL desde infinidad de lenguajes deprogramación. En <http://nehe.gamedev.net> se puede encontrar una buena canti-dad de ejemplos de aplicaciones OpenGLprogramadas con distintos lenguajes de pro-gramación.

En este artículo se muestra como programaraplicaciones gráficas con OpenGL desdeJava. En la sección 2sección 2sección 2sección 2sección 2 se muestra cual es elestado actual de Java y sus principales ca-racterísticas. En la sección 3sección 3sección 3sección 3sección 3 se dan referen-cias de algunos ejemplos de aplicacionesgráficas desarrolladas en OpenGL y Java.La sección 4 sección 4 sección 4 sección 4 sección 4 muestra como desarrollar unaaplicación en OpenGL y Java utilizando elmétodo de rellamada, como combinar com-ponentes Swing con OpenGL y finalmentecomo convertir estas aplicaciones en applets.La sección 5 sección 5 sección 5 sección 5 sección 5 es una recapitulación de conse-jos que se deben tener en cuenta al progra-mar OpenGL desde Java. Finalmente, lasección 6sección 6sección 6sección 6sección 6 indica al lector interesado dondeconseguir más información.

2. Estado Actual de JavaJava es un excelente lenguaje de programa-ción para desarrollar todo tipo de aplicacio-nes, desde pequeñas aplicaciones para equi-pos de sobremesa hasta grandes aplicacio-nes corporativas basadas en Internet, pasan-do por aplicaciones para dispositivos móvi-les, como teléfonos o PDAs.

En el momento de escribir este artículo laversión estable de Java 2 Standard Edition eslas 1.5, también llamada 5.0, y desde lapágina web de Sun <java.sun.com> se pue-de descargar la nueva versión 6.0 (Mustang)en su versión beta.

2.1. Características de JavaLas principales características de Java son [1]:

Java es multiplataforma, el mismo códigocompilado Java se puede ejecutar bajo unagran cantidad de sistemas operativos (OS X,Solaris, Linux, Microsoft XP, etcétera), y unagran cantidad de plataformas hardware(PowerPC, Intel, Sun, etcétera).

Java es orientado a objetos. Todo en Java esun objeto (excepto los tipos de datos primiti-vos, pero para estos tipos Java proporciona losrecubridores, (wrappers en inglés).

Java hace control estricto de tipos.Java es seguro, tanto desde el punto de vista

del programador, como desde el punto de vistadel usuario.

La concurrencia es una de las característi-cas del lenguaje, no es necesario importarlibrería externas; además, Java está orientadoa la programación en red desde sus inicios.

Existe un sinfín de falsas creencias alrededorde Java, que han quedado en el inconscientecolectivo de los programadores desde sulanzamiento, y que se han ido heredando degeneración en generación de programado-res, la más extendida es que Java es unlenguaje de programación lento porque esinterpretado. Esto era cierto para las prime-ras versiones de Java, pero desde la incorpo-ración de la tecnología JIT (del inglés just intime compilation) [2] se superó el problemade la lentitud de ejecución. Brevemente, latecnología JIT consiste en que la primera vez

que se llama a un método su código escompilado, en tiempo de ejecución, a códigonativo de la máquina donde se ejecuta laaplicación, y se almacena, de tal modo que lapróxima vez que se llame al mismo métodoya se ejecuta el código nativo del método. Sinuestras aplicaciones están constantementeejecutando un pequeño conjunto de méto-dos (como en el caso de los juegos porordenador por ejemplo) la tecnología JIT daexcelentes resultados desde el punto de vistadel tiempo de ejecución. Es más, ya que lacompilación se realiza en tiempo de ejecu-ción, algunos autores [9] sostienen que lavelocidad de ejecución de Java superará alenguajes como C/C++ y Fortran ya que sedispone de más información, en el momentode la compilación, que con la compilación"estática" de los lenguajes "clásicos".

Dentro de la comunidad Java se ha hecho ungran esfuerzo por mostrar las prestacionesde este lenguaje frente a otros lenguajes deprogramación. Para una visión general sepueden consultar las referencias [3] [4] [5][7] [8].

3. Ejemplos de aplicaciones gráfi-cas desarrollados en JavaExiste gran cantidad de herramientas para laconstrucción de aplicaciones gráficas, orien-tadas a la visualización de datos <http://www.kdnuggets.com/software/visualization.html>, a la creación de juegos para ordena-dor <http://ogre4j.org/drupal>, o a la ma-nipulación de imágenes, por citar algunas delas más comunes.

Andrew Davison ha publicado un excelentelibro titulado Killer Game Programming inJava [6]. En el capítulo de introducción

Programación de AplicacionesGráficas con OpenGL y Java

Óscar Belmonte FernándezDpt. Lenguajes y Sistemas Informáticos,Universitat Jaume I, Castellón

<oscar.belmonte@uji.es><oscar.belmonte@uji.es><oscar.belmonte@uji.es><oscar.belmonte@uji.es><oscar.belmonte@uji.es>

Resumen: en la actualidad la mayor parte de aplicaciones gráficas se desarrollan utilizando el lenguajede programación C/C++. El número de aplicaciones gráficas utilizando este lenguaje de programa-ción es abrumadoramente superior a las aplicaciones construidas con otros lenguajes de programa-ción. No obstante, hoy en día es posible utilizar las principales bibliotecas gráficas desde otros lengua-jes de programación, como por ejemplo Java. Las características de Java han hecho que el número deaplicaciones basadas en este lenguaje haya crecido de modo espectacular. Y las aplicaciones gráficasbasadas en OpenGL no han sido menos. Este artículo muestra cómo programar OpenGL desde Javautilizando la Java API for OpenGL (JOGL abreviadamente). Se mostrará que esta API ofrece un estilo deprogramación de aplicaciones gráficas con OpenGL muy similar al que se utiliza con C/C++ y glut. Severá, asimismo, como integrar el lienzo para dibujar gráficos OpenGL con componentes Swing, paracrear interfaces de usuario ricas.

Palabras clave: gráficos interactivos, Java, OpenGL.

novática nº 184 noviembre-diciembre 200652

secciones técnicas Informática Gráfica

secciones técnicas

muestra enlaces a numerosos juegos porordenador desarrollados en Java.

4. Cómo se construye una aplica-ción OpenGL con JavaSun, ha hecho disponible un API con el quepoder programar OpenGL desde Java, y estaAPI se ha desarrollado siguiendo un JavaSpecification Request, lo que significa que elproceso está abierto a todo aquel desarrol-lador interesado en contribuir en la especifi-cación. La última versión es la JSR-231 beta0.5. <https://jogl.dev.java.net/>. Este APIproporciona acceso a la especificaciónOpenGL 2.0, así como a extensiones de losfabricantes (incluye el lenguaje para shadersCg de Nvidia).

Los paquetes de esta API incluyen funcionesde las bibliotecas GLU y GLUT conocidas alos programadores de OpenGL, exceptoaquellas relacionadas con el sistema de ven-tanas y la gestión de eventos, que evidente-mente en Java se hace con AWT o Swing.

En esta especificación se puede programarOpenGL en modo de rellamada o en modoinmediato. En este artículo se muestra cómoprogramar OpenGL desde Java utilizando elmodo de rellamada.

4.1. Aplicaciones independientesLa idea subyacente a la programación deOpenGL desde Java en modo de rellamadaes la misma que cuando se escriben aplica-ciones de interfaz gráfica basadas en AWT oSwing, por un lado utilizamos componentescapaces de recibir eventos, en este caso delusuario, y por otro lado construimos clasesque reciben esos eventos gracias a queimplementan la interfaz necesaria y se hanregistrado para recibir los eventos. La figurafigurafigurafigurafigura

11111 muestra el procedimiento en el caso decomponentes Swing.

En el caso de OpenGL, por un lado las dosclases capaces de generar eventos sonGLCanvas y GLJPanel. La primera de ellaes análoga a las clases de interfaz gráfico enel paquete AWT (hay que tener cuidado alcombinarlas con clases Swing); la segundade ellas se integra perfectamente con lasclases del paquete Swing sacrificando velo-

cidad durante la fase de dibujo, es decir,dibujar utilizando GLCanvas es más rápidoque utilizando GLJPanel.

Por otro lado, si queremos que una clasereciba los eventos que generan las dos ante-riores clases debe implementar la interfazGLEventListener. Esta interfaz declara cua-tro métodos, que son los que se rellamaráncada vez que se produzca un evento sobreGLCanvas.

Estos cuatro métodos son:iiiiinit(GLAutoDrawable drawable); nit(GLAutoDrawable drawable); nit(GLAutoDrawable drawable); nit(GLAutoDrawable drawable); nit(GLAutoDrawable drawable); Este méto-do se llama inmediatamente después a la crea-ción de un contexto OpenGL.reshape(GLAutoDrawable drawable, int x, intreshape(GLAutoDrawable drawable, int x, intreshape(GLAutoDrawable drawable, int x, intreshape(GLAutoDrawable drawable, int x, intreshape(GLAutoDrawable drawable, int x, inty, int width, int height); y, int width, int height); y, int width, int height); y, int width, int height); y, int width, int height); Este método se llamadurante el primer dibujo de la escena y despuésque el componente a fijado su tamaño. Tam-bién se llama cada vez que la ventana cambiade tamaño.display(GLAutoDrawable drawable); display(GLAutoDrawable drawable); display(GLAutoDrawable drawable); display(GLAutoDrawable drawable); display(GLAutoDrawable drawable); Este esel evento al que debe responder el cliente cadavez que se procede a dibujar la escena.displayChanged(GLAutoDrawable drawable,displayChanged(GLAutoDrawable drawable,displayChanged(GLAutoDrawable drawable,displayChanged(GLAutoDrawable drawable,displayChanged(GLAutoDrawable drawable,boolean modeChanged, booleanboolean modeChanged, booleanboolean modeChanged, booleanboolean modeChanged, booleanboolean modeChanged, booleandeviceChanged); deviceChanged); deviceChanged); deviceChanged); deviceChanged); Este método es llamado cadavez que el dispositivo de visualización cambia.

Vamos a crear una sencilla aplicación quemuestre una esfera en modo alambre parailustrar como programar OpenGL desdeJava. La figura 2figura 2figura 2figura 2figura 2 muestra el esquema queguía la construcción de esta aplicación.

Figura 1. Un ejemplo sencillo de GUI. La clase que recibe los eventos del botón(Escuchador) debe implementar la interfaz ActionListener y registrarse para recibir loseventos generados por el botón. Cada vez que se pulse sobre el botón, se llamará almétodo actionPerformed(ActionEvent e) de esta clase.

Figura 2. En esta figura se muestra el marco para programar OpenGL desdeJava. La idea básica es que debemos utilizar un lienzo que nos de acceso aOpenGL (clase GLCanvas) y crear una clase que responda a los eventos deGLCanvas, implementando la interfaz GLEventListener y registrándose comoescuchador de estos eventos con el método addGLEventListener().

novática nº 184 noviembre-diciembre 2006 53

Informática Gráfica secciones técnicas

secciones técnicas

En este primer ejemplo se detalla todo elproceso de construcción y se muestra elcódigo completo de la aplicación. En losejemplos siguientes sólo se mostrará las par-tes del código que sean de interés. El códigocompleto de este primer ejemplo aparece enla figura 3figura 3figura 3figura 3figura 3.

Lo primero que se necesita es importar lasclases que se van a utilizar. JOGL (Java APIfor OpenGL) está formado por seis paque-tes, de ellos se importan clases de los paque-tes: javax.media.opengl, javax.media.opengl.GLU, y com.sun. opengl.util, el resto de

paquetes (javax.awt, javax.awt.event yjavax.swing) incorporan las clases necesa-rias para construir la interfaz gráfica deusuario (GUI).

La única clase que forma la aplicación es laque recibe los eventos de GLCanvas, por lotanto debe implementar la interfazGLEventListener. Como ya sabemos estainterfaz declara cuatro métodos, que seránlos que debemos definir para responder acada uno de los cuatro eventos queGLCanvas es capaz de generar (tres en rea-lidad, displayChanged() no se implementa).

Veamos qué se hace en cada uno de estosmétodos. El primero que aparece en el lista-do es init() donde vamos a definir las propie-dades de OpenGL para esta aplicación. Eneste ejemplo tan sencillo lo único que defini-mos es el color de borrado mediante el mé-todo glClearColor() de la clase GL. Y aquíaparece el primer detalle en el que debefijarse el programador de OpenGL al utilizarJava y el modelo de rellamada: el acceso a losmétodos de OpenGL se hace a través de laclase GL y la instancia de esa clase se debela instancia de esa clase se debela instancia de esa clase se debela instancia de esa clase se debela instancia de esa clase se deberecuperar del parámetro GLAutoDrawablerecuperar del parámetro GLAutoDrawablerecuperar del parámetro GLAutoDrawablerecuperar del parámetro GLAutoDrawablerecuperar del parámetro GLAutoDrawablecon que se llama a init(), y nunca crear unacon que se llama a init(), y nunca crear unacon que se llama a init(), y nunca crear unacon que se llama a init(), y nunca crear unacon que se llama a init(), y nunca crear unainstancia de la clase GL nosotros mismos,instancia de la clase GL nosotros mismos,instancia de la clase GL nosotros mismos,instancia de la clase GL nosotros mismos,instancia de la clase GL nosotros mismos,menos aún declararla atributo de la clasemenos aún declararla atributo de la clasemenos aún declararla atributo de la clasemenos aún declararla atributo de la clasemenos aún declararla atributo de la clasepara poder acceder a ella desde nuestrospara poder acceder a ella desde nuestrospara poder acceder a ella desde nuestrospara poder acceder a ella desde nuestrospara poder acceder a ella desde nuestrospropios métodospropios métodospropios métodospropios métodospropios métodos. Esto se debe a queGLAutoDrawable está ligada al contextográfico correcto con cada llamada a los mé-todos de rellamada. Si creamos nosotrosmismos una instancia de la clase GL noestará ligada a ningún contexto gráfico váli-do y se producirá un error en nuestra aplica-ción al intentar utilizar la instancia.

El siguiente método de la interfazGLEventListener que se define es reshape().En este método, al igual que en init(), acce-demos a la instancia de la clase GL recupe-rándola del atributo GLAutoDrawable. Losotros parámetros del método indican la po-sición de la esquina superior izquierda, elancho y alto de la ventana. En este métododefinimos el tipo de proyección que vamos autilizar, perspectiva en este caso; iniciamosla matriz modelo-vista con la identidad, yfinalmente dejamos cargada esta matrizcomo la actual.

El tercer método de este sencillo ejemplo esdisplay() donde realizamos todas las tareasde dibujo. De nuevo, lo primero que hace-mos es recuperar una instancia de la claseGL a través del parámetro GLAutoDrawable.Y creamos dos instancias, locales a estemétodo, de las clases GLU y GLUT. Comoya he comentado, a través de estas clases setiene la misma funcionalidad que a través delas funciones que en C empiezan por glu* yglut* respectivamente, excepto las relaciona-das con la gestión de ventanas. Y aquí esdonde aparece el segundo detalle que debe-mos fijar al programar OpenGL utilizandoJava y el modelo de rellamada: nunca debe-nunca debe-nunca debe-nunca debe-nunca debe-mos declarar como atributos de nuestramos declarar como atributos de nuestramos declarar como atributos de nuestramos declarar como atributos de nuestramos declarar como atributos de nuestraclase instancias de GLU y GLUT para acce-clase instancias de GLU y GLUT para acce-clase instancias de GLU y GLUT para acce-clase instancias de GLU y GLUT para acce-clase instancias de GLU y GLUT para acce-der a ellas desde los métodos de rellamada.der a ellas desde los métodos de rellamada.der a ellas desde los métodos de rellamada.der a ellas desde los métodos de rellamada.der a ellas desde los métodos de rellamada.Siempre deberemos crear instancias de ellasSiempre deberemos crear instancias de ellasSiempre deberemos crear instancias de ellasSiempre deberemos crear instancias de ellasSiempre deberemos crear instancias de ellasen estos métodosen estos métodosen estos métodosen estos métodosen estos métodos. El resto del código es muysencillo de interpretar para los programado-res de OpenGL, simplemente se borra elbuffer de color con gl.glClear(), se aíslan lastransformaciones para la siguiente llamadaal mismo método mediante el par gl.glPushMatrix()-gl.glPopMatrix(), definimosla posición del punto de vista con glu.

Figura 3. Esta figura muestra el listado completo para una aplicacióngráfica en Java utilizando JOGL.

novática nº 184 noviembre-diciembre 200654

secciones técnicas Informática Gráfica

secciones técnicas

gluLookAt() y una transformación congl.glRotatef(), y finalmente dibujamos unaesfera en modo alambre con glut.glutWireSphere().

El cuarto de los métodos que debemos defi-nir displayChanged(), como he comentadoanteriormente no está implementado en laversión actual de JOGL, sencillamente lodejamos vacío.

Nótese que todos estos métodos ya son co-nocidos por todo aquel que utiliza C/C++para programar OpenGL, y que la interfazde programación para OpenGL utilizandoel modelo de rellamada es prácticamenteigual que en el caso de C, a excepción del parde detalles que se debe fijar, por lo que lacurva de aprendizaje de programación deOpenGL desde Java resulta muy suave paralos programadores de OpenGL en C.

El código completo de los ejemplos queaparecen en este artículo se puede encontraren <http://www4.uji.es/~belfern/JOGL/Ejemplos/>.

4.2. Uso de JOGL y SwingNuestras aplicaciones gráficas, en general,no sólo muestran un lienzo OpenGL, sinoque además nos permiten interaccionar conla aplicación a través de una interfaz gráficade usuario, que puede estar compuesta porbotones, barras de deslizamiento, cajas deselección y todo el arsenal de componentes

gráficos que Swing pone a nuestra disposi-ción.

Utilizar lienzos OpenGL e interfaces de usua-rio Swing es muy sencillo siempre que sefijen, como en el apartado anterior, unassencillas reglas de programación. Comoejemplo se va a mostrar una sencilla aplica-ción con un lienzo OpenGL que muestre unaesfera sólida rotando en torno al eje de lasequis y que se controla mediante una muysencilla interfaz programada utilizandoSwing. La rotación se iniciará cuando sepulse el botón Inicio (se creará un hilo,instancia de la clase Thread, encargado de irincrementando el ángulo de rotación) y sedetendrá al pulsar el botón Parar (se destrui-rá el hilo).

En la figura 4figura 4figura 4figura 4figura 4 se muestra la arquitectura deesta aplicación. En esta figura sólo se mues-tra el código relevante al tema que estamostratando. Lo ideal en estos casos es utilizarun patrón Modelo-Vista-Controlador paradesarrollar la aplicación, pero no lo haremospara que el lector pueda centrar su atenciónen cómo combinar Swing con JOGL.

La primera diferencia con respecto al senci-llo ejemplo del caso anterior es que nuestranueva clase Principal implementa no sola-mente la interfaz GLEventListener, sino tam-bién la interfaz ActionListener, de este modose podrá registrar como escuchadora de loseventos que produzcan los botones que in-

cluye la interfaz de usuario. Por otro lado, laclase Animador sirve exclusivamente paracrear sobre ella un Hilo que controle larotación de la esfera, y es ella la queinteraccionará con el lienzo OpenGL cadavez que haya que dibujar la escena.

Como la clase Principal implementa lainterfaz ActionListener, estamos obligadosa definir el método actionPerformed(), y aregistrar la clase Principal como escuchadorade los eventos de los botones. Este método sellama cada vez que se pulsa uno de los dosbotones (registramos Principal comoescuchadora de los dos botones), y simple-mente lanza un hilo de control de la rotación,si es que no existe ninguno, o detiene el hilode control de la rotación, si es que existe uno.

El detalle verdaderamente importante locontiene la clase Animador en su métodorun(). En este método se fuerza el dibujo dellienzo OpenGL, pero al hacerlo, no se llamadirectamente al método display() de la clasePrincipal, sino que se fuerza el dibujo lla-mando al método repaint() de GLCanvas.

Este es el nuevo detalle que debemos fijar alprogramar OpenGL desde Java en modo derellamada: Nunca debemos llamar a losNunca debemos llamar a losNunca debemos llamar a losNunca debemos llamar a losNunca debemos llamar a losmétodos de la interfaz GLEventListenermétodos de la interfaz GLEventListenermétodos de la interfaz GLEventListenermétodos de la interfaz GLEventListenermétodos de la interfaz GLEventListenerdesde hilos distintos al que controla adesde hilos distintos al que controla adesde hilos distintos al que controla adesde hilos distintos al que controla adesde hilos distintos al que controla aGLEventListener.GLEventListener.GLEventListener.GLEventListener.GLEventListener. En general, nunca llama-remos de modo explícito a los métodos de lainterfaz GLEventListener.

Figura 4. Modelo de eventos para la clase GLCanvas. Para recibir los eventos que genera GLCanvas se debe crear una clase queimplemente la interfaz GLEventListener. También se muestra la clase Animador, encargada de iniciar y detener la animación.

novática nº 184 noviembre-diciembre 2006 55

Informática Gráfica secciones técnicas

secciones técnicas

Referencias

[1] K. Arnold et al. El lenguaje de programaciónJava. Addison-Wesley, 4ª Edición, 2005. ISBN:978-0201704334.[2] J. Aycock. "A Brief History of Just-In-Time".ACM Computing Surveys, Vol. 35(2), pp: 97-113,2003.[3] R. F. Boisvert, J. Moreira, M. Philippsen, R.Pozo. "Java and Numerical Computing". IEEEComputing in Science and Engineering, Vol. 3(2),pp: 18-24, 2001.[4] J. M. Bull, L. A. Smith, M. D. Westhead, D. S.Henty, R. A. Davey. "A Benchmark Suite for HighPerformance Java", Concurrency: Practice andExperience, Vol. 12, pp: 375-388, 2000.[5] J. M. Bull, L. A. Smith, L. Pottage, R. Freeman."Benchmarking Java against C and Fortran forScientific Application". Proceedings of the 2001joint ACM-ISCOPE conference on Java Grande, pp:97-105, 2001.[6] A. Davison. Killer Game Programming in Java.O’Reilly. 2005. ISBN: 978-0596007300.[7] Java Grande Forum. <http://www.javagrande.org>.[8] J.P.Lewis, Ulrich Neumann. Performance ofJava versus C++. <http://www.idiom.com/~zilla/Computer/javaCbenchmark.html>.[9] Kirk Reinholtz. "Java will be faster than C++".ACM SIGPLAN Notice, Vol. 35(2), pp: 25-28, 2000.[10] Gene Davis. Learning Java Bindings forOpenGL (JOGL). Authorhouse, 2004. ISBN: 978-1420803624.

4.3. AppletsSi hemos tenido la precaución de aislar ennuestro código la construcción de la interfazde usuario, para convertir nuestra aplica-ción en un applet debemos seguir las mismasreglas que para convertir en applet cualquierotro tipo de aplicación.

Esta vez nuestra clase extenderá a JApplet yen el método init() de la clase JApplet escri-biremos el código necesario para crear ellienzo OpenGL y el resto de la interfaz deusuario. En la figura 5figura 5figura 5figura 5figura 5 se muestra los cam-bios necesarios.

Con estos simples cambios hemos consegui-do que nuestra aplicación funcione tantocomo una aplicación independiente comoun applet para incrustarlo en nuestra pági-nas web. El único detalle es que un usuarioque desee ver nuestra página web, con unapplet utilizando JOGL, deberá tener insta-lado JOGL en su máquina, de lo contrario lamáquina virtual de Java no encontrará lasclases necesarias para ejecutar la aplicación.

Para evitar el problema de la dependencia denuestra aplicación de ciertas bibliotecas,podemos utilizar la tecnología Java WebStart de Sun. Esta tecnología, que está in-cluida en el Java desde la versión 1.4, seencarga de comprobar que en la máquinacliente existen las bibliotecas necesarias paraejecutar la aplicación, y de no ser así es capazde descargar las bibliotecas ausentes antesde ejecutar la aplicación. Y todo esto demodo transparente al usuario.

5. ResumenEn este artículo se muestra como construiruna aplicación gráfica utilizando Java yOpenGL en modo de rellamada. El procedi-miento es muy similar al que se utiliza cuan-

do se programa OpenGL desde C/C++utilizando la biblioteca glut.

La idea es análoga a la utilizada al progra-mar interfaces de usuario basadas en Swing:un lienzo OpenGL (clase GLCanvas) es ca-paz de generar eventos (init(), reshape(),display() y displayChanged() y para respon-der a ellos lo hemos de hacer desde una claseque implemente la interfaz GLEventListener.

Las tres máximas que hemos de tener siem-pre presente son:

Las instancias de esa clase GLCanvas sedeben recuperar a partir del parámetroGLAutoDrawable con que se llama a losmétodos declarados en la interfazGLEventListener, y nunca se deben crearcon el operador new().

Nunca debemos declarar en nuestras cla-ses atributos de tipo GLU o GLUT paraacceder a ellas desde los métodos derellamada. Siempre deberemos crear instan-cias de estos tipos en los métodos de lainterfaz GLEventListener.

Nunca debemos llamar a los métodos dela interfaz GLEventListener desde hilos dis-tintos al que controla a GLEventListener.

6. Información adicionalLa página imprescindible para conocer laJava API for OpenGL (JOGL) es la delproyecto <https://jogl.dev.java.net/>.

En NeHe <http://nehe.gamedev.net> en-contraremos código de los ejemplos paraaprender OpenGL portado a JOGL.

En la página web de [6] <http://fivedots.coe.psu.ac.th/~ad/jg/> disponemos de unpar de capítulos, no incluidos en el libro, queintroducen a la programación de JOGL conejemplos muy descriptivos.

Figura 5. Modificaciones para convertir nuestra aplicación en un applet.

Podemos ver ejemplos impresionantes pro-gramados en JOGL y utilizando la tecnolo-gía Java Web Start en <https://jogl-demos.dev.java.net/>. Para ver estos ejem-plos no es necesario que tengamos la APIinstalada.

Un buen libro para iniciarse en la programa-ción de JOGL y conteniendo numerososejemplos es [10]. Lo podemos comprar di-rectamente al autor desde su página web<http://www.genedavissoftware.com/books/jogl/>

En la página web de Sun <http://java.sun.com/developer/JDCTechTips/2005/tt0208.html#1> encontraremos aún más informa-ción sobre estos temas.

novática nº 184 noviembre-diciembre 200656

secciones técnicas Redes y servicios telemáticos

secciones técnicas

1. IntroducciónInternet es una red mundial formada pormillones de ordenadores de diversos tipos yplataformas, conectados entre sí por mediode equipos de comunicación cuya funciónprincipal es la de localizar, seleccionar, eintercambiar información desde el lugar endonde se encuentra hasta aquel donde hayasido solicitada, utilizando un mismo con-junto de protocolos de comunicaciones lla-mado TCP/IP [23].

A pesar de su complejidad, Internet se puededescribir de manera jerárquica desde un pun-to de vista macroscópico, en el que se puedever como un sistema formado por más de16.000 Sistemas Autónomos (en adelanteAS) [14] (conjunto de redes IP interco-nectadas por routers y que conforman unaentidad administrativa) que interactúan paracoordinar la entrega del tráfico IP.

Este conjunto de AS's da lugar a una tupidamalla de interconexiones originando un pro-blema de encaminamiento en el puede haberhasta 65.000 AS's de origen y destino por losque circula constantemente información.Como acabamos de mencionar, uno de losproblemas más importantes de este esquemaes la correcta localización y entrega de lainformación entre origen y destino; en otraspalabras: el problema del encaminamiento.

El protocolo interdominio Border GatewayProtocol (en adelante BGP) [20] se desarro-lló explícitamente para ser utilizado en redesTCP/IP, convirtiéndose en el protocolo deencaminamiento exterior (o interdominio)estándar en Internet. El objetivo del BGP esgarantizar la alcanzabilidad de los paquetesIP entre origen y destino, sin tener en cuentala optimización de rutas. En consecuencia,no es tarea de BGP la búsqueda de una rutaóptima global. Esto se debe, por una parte, alas restricciones impuestas en las políticasde encaminamiento elegidas por el adminis-trador y, por otra parte, al carácter de proto-colo de vector distancia de BGP, llamadovector-camino (en contraposición con pro-tocolos de estado de enlace) [3].

En la figura 1figura 1figura 1figura 1figura 1 se muestra el esquema deinterconexiones en Internet. Los círculosgrises representan AS's, es decir, unidadesadministrativas. Como puede verse en lafigura, los AS's intercambian informaciónde encaminamiento mediante BGP. Asimis-

mo, cada AS está formado por diferentessubredes conectadas entre routers que utili-zarán el protocolo intradominio elegido porel administrador.

Como ya hemos mencionado, el protocoloBGP permite a los administradores de losAS's configurar manualmente las políticasde encaminamiento en los routers borde (verfigura 1figura 1figura 1figura 1figura 1). Estas políticas administrativaspermiten tomar decisiones relativas a la se-lección, anuncio y recepción de las rutas.

El escenario en el que vamos a centrar nues-tra investigación es el encaminamientointerdominio, es decir entre AS's diferentes,los cuales se interconectan mediante enlacesdedicados o puntos de accesos públicos a laRed.

Así, en la sección 2sección 2sección 2sección 2sección 2 se describe un algoritmogenético novedoso al que hemos denomina-do Algoritmo Genético del Ciervo (en ade-lante AGC), inspirado en el comportamien-to social y reproductor de los ciervos. En lamisma sección se formula matemáticamenteel problema que abordamos y la adaptacióndel AGC a dicho problema. En la sección 3sección 3sección 3sección 3sección 3se recogen los resultados más destacablesdel funcionamiento del AGC. Finalmente, enla sección 4sección 4sección 4sección 4sección 4 se presenta las conclusiones másimportantes de este trabajo y se apunta a lautilización del AGC como parte fundamentalde la estructura de un ente supervisor de Internet,que necesita de la rapidez de convergencia delAGC para su óptimo funcionamiento. Porúltimo se discuten posibles extensiones de estetrabajo a otros problemas

2. Algoritmo Genético del CiervoEl modelo que presentamos está basado enel comportamiento social y reproductor delos ciervos, que dentro de la evolución de lasespecies es tremendamente selectivo. Asi-mismo, hay que destacar que los últimostrabajos desarrollados por Ahn yRamakrishna [1] utilizan el torneo como

método de selección, lo que sugiere que lasmejoras de los algoritmos genéticos (en ade-lante GA's) apuntan a variantes en este sen-tido, como demuestran tanto [11] como [1]con la eficacia de sus métodos.

El GA social desarrollado en la referencia[11], demostraba que si el criterio de selec-ción es muy restrictivo y, por otro lado secompletaba la población obtenida por cru-ces y mutaciones convencionales, con indivi-duos generados aleatoriamente a los quedenominó inmigrantes, se obtenía una bue-na solución en las primeras generaciones.Basándonos en este comportamiento, en estetrabajo se desarrolla un nuevo modelo mejo-rado en el que se incluye la eliminación demínimos locales, gracias a la incorporaciónde elementos perturbadores que se trataránmás adelante.

El problema que abordamos es el de laoptimización del encaminamiento enInternet, por lo que el AGC necesita conocerla topología de Internet para determinar lasrutas entre dos sistemas autónomos (AS's).Para ello, utilizará la información generadapor el proyecto Route Views (en adelanteRV) <http://www.routeviews.com/> del"Advanced Network Technology Center" dela Universidad de Oregón. El proyecto RVobtiene múltiples vistas de la tabla deencaminamiento global que permitirá a losrouters de RV disponer de una completainformación de encaminamiento gracias a lainteracción con distintos AS's distribuidospor todo el mundo. Es por tanto una potenteherramienta destinada a obtener informa-ción en tiempo real acerca de los sistemas deencaminamiento globales, desde la perspec-tiva de diferentes backbones1 y localizacio-nes alrededor de Internet. Básicamente estosdatos dan la información completa sobre lasrutas empleadas, en la realidad, para alcan-zar desde un nodo origen un nodo destino,manejando para ello mas de ocho millonesde rutas.

Algoritmo bioinspirado para laoptimización de rutas en Internet

José Luis Gahete Díaz, Fer-nando Gómez GonzálezEscuela Técnica Superior de Ingeniería(ICAI) Universidad P. Comillas, Madrid

{jlgahete, fgomez}@dsi.icai.upcomillas.es{jlgahete, fgomez}@dsi.icai.upcomillas.es{jlgahete, fgomez}@dsi.icai.upcomillas.es{jlgahete, fgomez}@dsi.icai.upcomillas.es{jlgahete, fgomez}@dsi.icai.upcomillas.es

Resumen: en este trabajo presentamos un novedoso algoritmo genético al que hemos denominadoAlgoritmo Genético del Ciervo. Este algoritmo está inspirado en el comportamiento social y reproductorde los ciervos, siendo particularmente idóneo para la optimización de rutas en el problema delencaminamiento en Internet. Asimismo, mostramos las características más importantes del algoritmoen términos de convergencia. Finalmente exponemos su aplicabilidad en el contexto de la supervisióndel tráfico entre Sistemas Autónomos en Internet.

Palabras clave: algoritmos genéticos, encaminamiento. Internet, optimización, sistemas autónomos.

novática nº 184 noviembre-diciembre 2006 57

Redes y servicios telemáticos secciones técnicas

secciones técnicas

Figura 1. Esquema simplificado de Internet.

Centrándonos en el objeto de este trabajo, elAGC consiste en reproducir artificialmentela vida de los ciervos para obtener rutasmejores entre AS's que las obtenidas por losalgoritmos que están al uso. El modelo estábasado, por tanto, en el comportamientosocial y reproductor de los ciervos que, den-tro de la evolución de las especies, es muyselectivo. Este algoritmo de encaminamientodebe utilizar la misma métrica que BGP, esdecir, el mínimo número de saltos.

2.1 Formulación matemática del pro-blemaA partir de los datos aportados por el pro-yecto RouteViews, en forma de ficheros dedatos (tablas de encaminamiento globalesde Internet) y obtenidos mediante la colabo-ración e intercambio de tablas de rutas de unnúmero elevado de AS's, se obtiene la topo-logía de la red necesaria para nuestro mode-lo. El problema que afrontamos tiene sufundamento en la teoría de grafos [2], dadoque partimos de una red de comunicacionesformada por AS's (nodos) y conexiones físi-cas (arcos). Así, el modelo que se propone eneste trabajo es el siguiente:

Sea M el conjunto de todos los nodos, seaV(M) el conjunto formado por todos losarcos que enlazan estos nodos, es decir, unsubconjunto del producto cartesiano MxM:

V (M)⊂ M × M = {(i,j) ⁄ i, j ∈ {1,...,m}} (1)

Por tanto, disponemos de una red o grafoG ≡ (M, V (M)) como soporte para obtenertodos los caminos posibles entre dos puntoscualesquiera que supondremos finito, concardinalidad m, y a los que identificaremoscon los números sucesivos de 1 a m. Seimpone, como condición, que la red sea

fuertemente conexa. Se dice que el nodo i esadyacente a otro j cuando existe al menosuno de los dos arcos (i, j) y (h, k). Dosarcos(i, j) y (h, k) son adyacentes si i = k, j =h, i = h o j = k

La etiqueta de un arco o de una arista tam-bién recibe el nombre de peso o coste Cij , encuyo caso el grafo recibiría el nombre degrafo con pesos o grafo valorado. En nuestrocaso el coste Cij será igual a 1 ya que se buscala alcanzabilidad entre dos AS's .

El problema que abordamos trata de darsolución al problema del encaminamientoque consiste en visitar, partiendo de un nodoorigen, otro conjunto de nodos hasta llegaral nodo destino, de tal forma que la distanciarecorrida sea mínima. Se supone que cadanodo se visita una sola vez.

Dado un grafo G, un camino entre los vérti-ces m1 y m n+1 y es una secuencia de arcosadyacentes cuyo primer origen es m1 y cuyoúltimo extremo es m n+1, esto es, una secuen-cia de nodos m1 y arcos vi , m1 , v1 , ,m2 , v2 ,...,mn , vm ,..., mn+1 , cuyo origen es el vérticem1 y cuyo destino es el vértice mn+1 y quecontiene n arcos vi = {mi ,mi+1}, siendo 1 ≤ i≤ n. La longitud de un camino es n, es decir,el total de arcos.

La matriz de adyacencia de G, respecto a losvértices anteriores, es una matriz booleanaX cuadrada, de dimensión n × n, cuyo ele-mento es tal que:

Para dos nodos dados, h y k, el problema aresolver consiste en encontrar un camino delongitud mínima con origen en h y final en k.Es decir, se trata del problema de opti-mización

(3)

donde la variable de decisión

sujeto a:

(4)

(del vértice h sale un arco, pero no lleganinguno)

(5)

(al vértice k llega un arco, pero no de él nosale ninguno)

(6)

(en todo vértice del camino lo que "entra" hade ser igual a lo que "sale")

(hay vértices que no forman parte de la ruta)

elemento i, j de la matriz de adyacencia (sientre i y j no hay un arco x ij forzosamentees nula; si

podrá interesar o no utilizar dicho arco).

Si se trata de una red valorada donde el arco(i, j) tiene asociado el coste cij la función aminimizar es

En el problema planteado cij = 1.

El conjunto de restricciones asegura quecada nodo aparezca una sola vez en la ruta,la continuidad de la ruta y que todos losnodos de la red están conectados no quedan-do ninguno aislado.Este modelo, como sepuede observar, es lineal y tiene una soluciónexacta, pero como se ha explicado es unproblema "NP- Hard" [10] que tiene unostiempos de ejecución en ordenador muy ele-vados, por lo que es inviable su resolución

(2)

∑∑= =

n

i

n

jijx

1 1

Min

0;11

,1

, == ∑∑==

n

ihi

n

jjh xx

jixij ,}1,0{ ∀∈

0;11

,1

, == ∑∑==

n

jjk

n

iki xx

∑ ∑= =

≠≠∀=n

i

n

jpjip xx

1 1

k p h,p ,

∑=

≠≠∀≤n

iipx

1k p h,p ,1

ijij axji ≤∀ ,

1=ija

ij

n

i

n

jij xc∑∑

= =1 1

⎩⎨⎧=

∈ )(),(,1

,0

MVjisi

casootroenija

ija

novática nº 184 noviembre-diciembre 200658

secciones técnicas Redes y servicios telemáticos

secciones técnicas

Figura 2. Ejemplo de encaminamiento y su codificación.

S

N1

N2 Nk-1

Nk

D

S N1 N2 … Nk-1 Nk D Cromosoma

Posición 1 2 3 l-2 l-1 l

por métodos exactos. Un problema es NP(no polinomial) si existe un algoritmo no-determinista, cuyo tiempo de ejecución esuna expresión polinomial en el tamaño de laentrada, es decir, se disparan los tiempos deejecución al aumentar muy poco el númerode variables. Estos problemas se clasificanen "fáciles" o tratables y "difíciles" o intrata-bles en función de si existe un algoritmopolinomial de tiempo para el primer caso; oun algoritmo superpolinomial en el segun-do.

Es por ello que los problemas NP se suelenresolver por medio de métodos heurísticosque permitan explorar el ámbito de las solu-ciones y obtener un óptimo, que si bienpuede no ser la mejor, si es un valor válidoobtenido en un tiempo razonable. Es habi-tual que los distintos métodos clásicos desa-rrollados para resolver este tipo de proble-mas manejen una solución cada vez. Porotro lado, los más modernos, y dado elavance en tecnologías de la computación,trabajan con más soluciones a la vez por loque la exploración del ámbito de solucioneses más abundante y, por tanto, aplicando loscriterios adecuados de convergencia de solu-ciones, es más fácil mejorar en la obtencióndel valor óptimo a la hora de seleccionar unalgoritmo para resolver este problema.

2.2 Descripción del Algoritmo Genéticodel CiervoEmpleamos cromosomas de longitud varia-ble, donde los genes representan los nodosque componen la ruta entre el par origen-destino, previamente fijado. El cruceintercambia rutas parciales de los cromo-somas padres; el punto de cruce en amboscromosomas es el mismo identificador denodo por lo que aseguramos que las nuevasrutas son, a priori, buenas. No obstante, se hadiseñado una función que permite "arreglar"rutas con algunas anomalías procedentes delcruce (rutas con nodos repetidos, etc.)

El algoritmo desarrollado es un algoritmobio-inspirado en el que se trata de imitar laforma de vida de los ciervos. Este tipo de

algoritmos se han de desarrollar reprodu-ciendo el comportamiento exacto en la natu-raleza, constituyendo una alternativainnovadora a la hora de resolver problemas.Esta tendencia en el mundo de la investiga-ción de la inteligencia artificial [4] [5] [22]marca las nuevas tendencias en este tipo dedesarrollos. Es decir, todas las característi-cas reales de la naturaleza (probabilidadesde cruce, supervivencia, población, muta-ción, etc.) se trasladan al modelo.

El AGC consiste en la simulación de lascaracterísticas fundamentales de la vida delos ciervos. Es decir, lo mismo que el ciervotrata de evolucionar en las sucesivas genera-ciones hacia individuos más perfectos, fuer-tes y mejor dotados para sobrevivir, nuestropropósito es hacer evolucionar las solucio-nes del problema de encaminamiento haciauna solución óptima. Como se ha dicho, esteproblema consiste en minimizar el númerode arcos de la ruta entre cualquier par deAS´s.

Para ello el GA propuesto se desarrolla a lolargo de las siguientes etapas:1. Representación del problema.1. Representación del problema.1. Representación del problema.1. Representación del problema.1. Representación del problema. Elcromosoma del AGC se compone de unasecuencia de números enteros positivos querepresentan los identificadores de los nodos(AS's) por los que pasa una ruta. Por tanto,cada posición del cromosoma representa elorden en que es visitado un nodo en la ruta.La primera posición siempre será para elnodo origen, mientras que la última estaráreservada para el nodo destino. Elcromosoma codifica el problema incluyen-do los identificadores de los nodos desde elorigen hasta el destino basándose en la in-formación de la topología de la red propor-cionada por BGP. En la figura 2 figura 2 figura 2 figura 2 figura 2 mostramosun ejemplo genérico.

2. Población inicial.2. Población inicial.2. Población inicial.2. Población inicial.2. Población inicial. La población inicial esgenerada aleatoriamente con el método decodificación explicado anteriormente. No seha utilizado una inicialización heurística yaque ésta suele explorar sólo una pequeña partedel espacio de soluciones y nunca encuentra

una solución óptima global debido a la falta dediversidad en la población [15]. El gen de laprimera posición codifica el nodo origen, mien-tras que el gen de la segunda posición esseleccionado al azar del conjunto de nodosconectados con el origen. Cada vez que seselecciona un nodo, se analiza el cromosomapara evitar la aparición de bucles. Si éste es elcaso, hay una función encargada de "reparar"la ruta. Este proceso se repite hasta que sealcanza el nodo destino.

La población inicial en el AGC está com-puesta por tres generaciones de l cromosomascada una, a partir de la topología de Internetobtenida del Proyecto RV. Se crean tresgeneraciones de posibles soluciones al pro-blema del encaminamiento, ya que las hem-bras serán fértiles a partir del segundo año,y evolucionan en futuras generaciones con elobjetivo de conseguir una mejor solución.En cada generación, el AGC discriminará sila solución generada corresponde a un ma-cho o a una hembra, con el fin de representarfielmente la vida de los ciervos. La propor-ción de sexos al nacer es 1:1, es decir vienenal mundo tantos machos como hembras.Cada generación representa un año de vidade los ciervos. A continuación se evalúan lassoluciones correspondientes a esta pobla-ción aplicando la función objetivo.

3.3.3.3.3. Selección del macho dominante.Selección del macho dominante.Selección del macho dominante.Selección del macho dominante.Selección del macho dominante. Se de-termina cual es el macho dominante de entretodos los machos pertenecientes a las gene-raciones 3-8 (generaciones en las que losciervos machos está en disposición de pro-crear), es decir aquel cromosoma que tengacomo coste el menor. Para ello, se ha utiliza-do como operador de selección el torneo, envirtud del cual el mejor cromosoma machode un conjunto definido de generaciones"lucha" contra todos y cada uno de loscromosomas machos de dicho conjunto (ge-neraciones 3-8), siendo el tamaño del torneo2, al igual que en la naturaleza. El mejorcromosoma, denominado "macho dominan-te" será el padre de la siguiente generación.En la población inicial el macho dominantese encontrará en la generación 3.

novática nº 184 noviembre-diciembre 2006 59

Redes y servicios telemáticos secciones técnicas

secciones técnicas

Figura 3. Ejemplo de cruce.

CRUCE

S

N1

N2

N3

N4 N5 N6

D N7

Posibles puntos de

cruce: (3, 2) (5, 4)

N1

N2

N3

N4 N5 N6

D N7

S N1 N2 N4 N5 D S N1 N2 N3 N5 N6 N7 D

S N2 N3 N5 N6 N7 D S N2 N4 N5 D

4.4.4.4.4. Torneo. Torneo. Torneo. Torneo. Torneo. El macho dominante, antes decubrir a todas las hembras fértiles entre lageneración 3 y la 8, debe luchar contra todoslos demás machos. Como en la vida real,puede darse el caso de que un ciervo macho(un cromosoma con peor evaluación) ganeen la lucha al dominante, siendo esta posibi-lidad un primer mecanismo que evita que elAGC quede atrapado en un mínimo local.Otro proceso que permite huir de los míni-mos locales es la aparición de un ciervoasesino, circunstancia que, al igual que en larealidad, se da con una probabilidad remo-ta, hecho que es reflejado en el AGC, evitan-do así posibles mínimos locales. Este ciervo,denominado asesino, pasa a ser el dominan-te. Por otra parte, se introduce otro procesoperturbador en esta selección que consisteen reproducir el entrecruzamiento de corna-mentas, en cuyo caso morirán los dos. Portanto, se debe encontrar de nuevo un machodominante entre las generaciones 3 y 8 yrepetir el proceso. El ciervo asesino se co-rresponde a una mutación convencional enla que el salto que se da de la cuenca deatracción de un mínimo local puede ser im-portante porque el asesino puede tener unmaterial genético muy dispar.

En cambio, el entrecruce de cornamentascorrespondería a una mutación más suavedado que se busca el siguiente mejor candi-dato. La probabilidad de que estos hechosocurran en la realidad es muy baja. Paranuestro problema viene bien este hecho dadoque el esfuerzo que se necesita para salir deun mínimo local puede ser grande y no haygarantías de la salida de la cuenca de atrac-ción del mínimo local. Este proceso portanto penalizaría los tiempos de ejecución.

5. Reproducción (cruce). 5. Reproducción (cruce). 5. Reproducción (cruce). 5. Reproducción (cruce). 5. Reproducción (cruce). El operador cruceutilizado en esta tesis es el denominadocruce "en n-puntos" o cruce "n-puntual".

Permite intercambiar subrutas parciales en-tre los dos cromosomas seleccionados, demanera que cada hijo resultante representesolo una ruta. Este tipo de cruce producehijos con rasgos dominantes. Lógicamente,los dos cromosomas seleccionados para elcruce deben tener al menos un nodo encomún, además del origen y destino, nosiendo necesario que se encuentren en lamisma posición en ambos cromosomas; esdecir el cruce no depende de la posición queocupan los nodos en los cromosomas. En lafigura 3 [1] se muestra un ejemplo del proce-so de cruce.

El proceso de cruce comienza localizandolos puntos de cruce, tanto en el macho domi-nante como en la hembra. A continuación seelige al azar el cromosoma del cual se va aheredar la subruta (desde el origen al primerpunto de cruce). A partir de este momento serepite el proceso entre los puntos de cruceintermedios hasta que se alcance el destino.Se pueden ir heredando, alternativamente,subrutas pertenecientes unas veces al ma-cho dominante y, otras a la hembra.

Los puntos de cruce de los dos cromosomas,como se ha comentado anteriormente y pue-de verse en la figura 3figura 3figura 3figura 3figura 3, pueden ser diferentesen cada cromosoma. Es posible que aparez-can bucles tras la operación de cruce. Paraevitar esta posibilidad se ha desarrolladouna subrutina (función de recuperación) queelimina de la ruta los eventuales bucles, conun coste computacional realmente bajo. LaLaLaLaLafigura 4figura 4figura 4figura 4figura 4 [1] muestra este proceso.

El macho dominante cubrirá a todos loscromosomas hembras en edad de procrear(generación de la 3 a la 8). Se creará así unanueva generación que pasará a ser la genera-ción número 1. La primera generación (queya existía) pasa a ser la segunda y así sucesi-

vamente. En cada apareamiento podrá ha-ber como máximo 2 hijos y como mínimo 1.La probabilidad de cruce Pc es fijada alcomienzo. Dado que la probabilidad real decruce es 0,9, y apoyándonos en los trabajosde investigación de [12] [16] y [21], en lasejecuciones del caso práctico se utilizaráesta probabilidad. Se genera un número alea-torio Aleatorio_cruce del intervalo [0,1]. SiAleatorio_cruce Pc hay cruce. En este casoqueda por determinar el número de hijos.Para ello se genera otro aleatorio,Aleatorio_hijos, del intervalo [0,1] pudien-do darse dos casos:1. Que Aleatorio_hijos < 0.95. En este casose obtendrá un solo hijo.2. Que Aleatorio_hijos ≥ 0.95. En este casose obtendrán dos hijos.

6.6.6.6.6. Convergencia.Convergencia.Convergencia.Convergencia.Convergencia. Para comprobar la con-vergencia de la solución, comparamos lasmejores soluciones de las generaciones k y k-1, pudiendo ocurrir:

⎩⎨⎧><

− Converge1Diverge1

1

k

k

SS

Si diverge la mejor solución de la generaciónk tomará el valor de la k-1.

7.7.7.7.7. Evolución.Evolución.Evolución.Evolución.Evolución. Los pasos 3 al 5 se repetiránhasta alcanzar el número de generacionespredeterminado. Se ha comprobado que esenúmero de generaciones es 20 dado que elcomportamiento del AGC es muy selectivo yobtiene buenos resultados rápidamente.

8.8.8.8.8. Criterio de parada.Criterio de parada.Criterio de parada.Criterio de parada.Criterio de parada. Tal y como se señalaen el párrafo anterior el AGC se detendrácuando alcance el número de generacionesque se haya preestablecido. Otro criterioutilizado es el de conseguir una misma solu-ción óptima en tres generaciones sucesivas.Este criterio viene sugerido porque el proble-ma a resolver es una variable discreta (nú-

novática nº 184 noviembre-diciembre 200660

secciones técnicas Redes y servicios telemáticos

secciones técnicas

Figura 4. Ejemplo de la función que arregla cromosomas inválidos de cruce.

S

N2

N3

N1

N4

N5

D

Punto de cruce

S

N2

N3

N1

N4

N5

D

No Factible

Factible

S

N2

N3

N1

N4

N5

D

Buscar y eliminar genes “letales”

bucle S

N2

N3

N1

N4

N5

D

factible

factible

CRUCE

Eliminar bucles

02

46

80

12

3

4

5

6

78

910111213

14

15

16

17

1819

20

Figura 5. Ejecución del AGC Ruta 1907-1509.

novática nº 184 noviembre-diciembre 2006 61

Redes y servicios telemáticos secciones técnicas

secciones técnicas

0

5

10

150

12

3

4

5

6

78

910111213

14

15

16

17

1819

20

Figura 6. Ejecución del AGC Ruta 97-753.

Tabla 1. Resumen de resultados del AGC.

mero de saltos) cuyo valor máximo está entorno a 20 saltos. En este problema, y dadoque se trata de obtener una solución en untiempo razonable, se puede detener la ejecu-ción al obtener un buen valor aunque estesea un mínimo local. No obstante en lasejecuciones de los casos prácticos siempre semuestra las generaciones indicadas para versu evolución.

El AGC se caracteriza por ser muy rápido en laobtención de una buena solución. Esto se debea que el macho dominante es el mejor indivi-duo de toda la población y va transmitiendo sumaterial genético generación tras generaciónpermitiendo converger rápidamente aunquesea a un mínimo local. Es decir, en la operaciónde reproducción del AGC el macho dominanteestá transmitiendo material genético a las su-cesivas generaciones y en las que, además, secruzará posteriormente con las hembras detodas las generaciones con capacidad de re-producción.

Esto implica que a medida que se va evolu-cionando este material genético es cada vezmás coincidente. Por tanto, lo que se estáobteniendo son esquemas que cada vez se-rán de longitud y orden mayores. Esto supo-ne que cada vez habrá menos representantesde soluciones distintas y, al menos, se obten-drá rápidamente un óptimo local.

Para salir de ese óptimo local y explorarnuevas zonas de soluciones, las perturbacio-nes que se emplean, entrecruce de corna-mentas y ciervo asesino, pueden permitir darese salto del grupo de soluciones localespara ir hacia el óptimo global.

Estas perturbaciones introducen ese factor alea-torio propio de las mutaciones en los GA'sconvencionales, pero cabe destacar que el com-portamiento esperado a priori de cada uno deellos es diferente. Es decir, el entrecruce decornamentas lleva a la muerte de ambos púgi-les y es más que probable que el candidato amacho dominante, el cual habrá que localizaren todas las generaciones activas, tenga mu-

chas características comunes con el machodominante muerto, con lo que la probabilidadde explorar nuevas soluciones es menor.

En cambio la aparición del ciervo asesinosignifica que éste será el que se apareará y,por tanto, la probabilidad a repetir el con-junto de soluciones en curso es más remota;excepto en el caso en el que se encuentre yaen la cuenca de atracción del óptimo global.

3. Resultados y funcionamientodel AGCEn este apartado, se exponen los resultadosobtenidos después de realizar un conjuntode ejecuciones del AGC, donde se comprue-ba de forma empírica su convergencia. Comopuede observarse en la tablas incluidas enlas figuras 5 figuras 5 figuras 5 figuras 5 figuras 5 y 66666, para cada ejecución se fijael número de cromosomas de la poblacióninicial en 20, el número de generaciones acrear en 20 y la probabilidad de cruce en 0,9.Cada fila se corresponde con una genera-ción (véase columna 1), mostrándose el mejory peor resultado (columnas 2 y 3), en núme-ro de AS's que componen la ruta, el númerode ciervos machos y ciervos hembras (co-lumnas 4 y 5) creados, así como la ruta mejordesde un nodo origen a un nodo destino.Además se incluye un gráfico radial explica-tivo de la convergencia del AGC (parte dere-

cha de las figuras 5 y 6), donde los númerosexteriores 0-20 hacen referencia al númerode la generación y los números interiores alnúmero de saltos de la mejor ruta

Como se puede observar el AGC obtiene unabuena solución, en la mayoría de los casos,a partir de la sexta generación teniendo encuenta que en las tres primeras no se producecruce de material genético y por tanto co-rrespondería a la generación cero de un GAconvencional. En la tabla 1tabla 1tabla 1tabla 1tabla 1 se muestra unresumen de resultados obtenidos en un con-junto de ejecuciones entre las que se incluyenla expuestas anteriormente.

4. ConclusionesEn este trabajo hemos presentado un nuevoalgoritmo bioinspirado (AGC) que demues-tra ser una herramienta eficaz para la gene-ración de rutas óptimas en Internet. Estealgoritmo, se basa en la dinámica de lascomunidades de ciervos. La convergenciadel algoritmo es rápida, gracias a la incorpo-ración de elementos perturbadores (ciervoasesino y cruce de cornamentas), así como laherencia de gran parte del material genéticodel macho dominante.

En las referencias [8] y [9] se presenta unmodelo de ente supervisor, denominado

novática nº 184 noviembre-diciembre 200662

secciones técnicas Redes y servicios telemáticos

secciones técnicas

[1] C.W. Ahn, R.S. Ramakrishna. A genetic algorithmfor shortest path routing problem and the sizing ofpopulations. Dept. of Inf. & Commun., Kwangju Inst.of Sci. & Technol., South Korea. In ProceedingsEvolutionary Computation, IEEE Transactions, Vol 6,pp. 566-579, 2003.[2] R. Balakrishnan, K. Ranganathan. A textbook ofgraph theory, Springer-Verlag, Berlín, 2000. ISBN:0387988599.[3] U. Black. IP Routing Protocols, Prentice Hall, NewYork, 2000. ISBN: 0130142484.[4] P. Bentley. DIGITAL BIOLOGY. How Nature isTransforming our Technology. Headline, 2001.[5] M. Bonabeau, M. Dorigo, G. Theraulaz. SwarmIntelligence. From Nature to Artificial Systems. OxfordUniversity Press, 1999. ISBN: 0195131584.[6] I. Foster et al. The Anatomy of the GRID: EnablingScalable Virtual Organizations. Intl. J. SupercomputerApplications, 2001.[7] L. Gao. On inferring autonomous systemrelationships in the internet. In Proceedings IEEE/ACM Transactions on Networking 9(6):733-745, 2001.[8] J.L. Gahete Díaz, F. Gómez González, A. GarcíaSan Luis, M. Castro Ponce. Sistema global de aseso-ramiento basado en la generación automática derutas óptimas alternativas para la optimización delencaminamiento entre Sistemas Autónomos deInternet. In Proceedings Conferencia Ibero-America-na WWW/Internet 2005, Lisboa.[9] J.L. Gahete Díaz, F. Gómez González, A. GarcíaSan Luis, M. Castro Ponce. Observatorio de Internet:Modelo de supervisión, optimización y mejora globaldel encaminamiento de datos entre Sistemas Autóno-mos. In Proceedings Congreso Español de Informá-tica (CEDI), Granada (España), 2005.[10] M.R. Garey, D.S. Jonson. Computers andIntractability: A Guide to the Theory ofNPCompleteness. Freeman, San Francisco, CA, 1979.ISBN: 0716710447.[11] F. Gómez. Sistema de Gestión y Control deRedes Medioambientales. Tesis Doctoral ICAI, 1997.[12] J.J. Grefenstette. Optimization of control

Referencias parameters for genetic algorithms. IEEE Transactionson Systems, Man and Cybernetics SMC-16(1), pp.122-128, 1986.[13] J. Han, M. Kamber. Data Mining: Concepts andTechniques. Morgan-Kaufmann, San Mateo, CA, 2000.ISBN: 1-55860-489-8.[14] J. Hawkinson, T. Bates. Guidelines for creation,selection, and registration of an Autonomous System(AS). Requests For Comments 1930, 1996.[15] X. Hue. Genetic algorithms for optimization:Background and applications. Edinburgh ParallelComputing Centre, Univ. Edinburgh, Edinburgh,Scotland, Version 1.0, 1997.[16] J. Koza. Genetic Programming. On theProgramming of Computers by Means of NaturalSelección. MIT Press, Cambridge, MA., 1994.[17] G. Malkin. RIP Version 2. Request For Comments2453, 1998.[18] J. Moy. OSPF Version 2. Request For Comments2178, 1997.[19] University of Oregon. Proyecto Route Views,1997 <http://routeviews.org>.[20] Y. Rekhter, T. Li. A Border Gateway Protocol 4(BGP-4), Request For Comments 1771, 1995.[21] J.D. Schaffer, R.A. Caruana, L.J. Eshelman, R.Das. A study of control parameters affecting onlineperformance of genetic algorithms for functionoptimization. In Schaffer, pp. 51-60. Morgan KaufmanPublishers, San Mateo, CA, 1989. ISBN:1-55860-006-3.[22] M. Shipper. Machine Nature. The Coming Ageof Bio-Inspired Computing. McGraw-Hill, 2002. ISBN:0070582467.[23] T. Socolofsky, C. Kale. A TCP/IP Tutorial.Requests For Comments 1180, 1991.

1 Línea de gran capacidad a la que se conectan otraslíneas de menor capacidad a través de puntos deconexión llamados nodos. La traducción literal es"columna vertebral" o "espina dorsal".

Nota

Observatorio, cuya función consiste en ase-sorar a los AS's sobre cambios en sus políti-cas de encaminamiento con el fin de mejorarel tráfico de Internet. Para la realización deesta labor se necesita una rápida y potenteherramienta de simulación que obtenga, trasmúltiples ejecuciones, unas conclusiones demejora del encaminamiento global. El AGCse presenta como el algoritmo idóneo para larealización de esta función.

Los autores están trabajando en la aplica-ción de este algoritmo a problemas relacio-nados con la Calidad de Servicio (QoS) y laingeniería de Tráfico en redes de comunica-ciones. Hay que resaltar, que el AGC sepuede adaptar para el cálculo en topologíasponderadas (coste del enlace distinto de 1),lo cual le hace idóneo para este problemaconcreto en el que los pesos de los enlacesestán asociados a diversos parámetros deQoS. Asimismo se puede generalizar el pro-blema a redes dirigidas.

Futuros trabajos de investigación pueden irencaminados a resolver problemas deoptimización de aplicación industrial. Algu-nos de estos problemas como, por ejemplo,el problema del viajante con ventanas detiempo y múltiples rutas, o el problema de lasecuenciación óptima de tareas en un taller(job shop), se modelan con redes cuyo con-junto de nodos tienen una cardinalidad muyelevada. En estos modelos el AGC se presen-ta como un algoritmo idóneo por su rapidezde convergencia, por una parte, y por suversatilidad para modelar sistemasmultidimensionales ponderados, por otra.En algunos casos, se podrían requerir laimplementación de algoritmos híbridos quese ajustasen al problema a tratar.

novática nº 184 noviembre-diciembre 2006 63secciones técnicas

refe

renc

ias

auto

rizad

as

Las habituales referencias que desde 1999 nos ofrecen los coordinado-res de las Secciones Técnicas de nuestra revista pueden consultarse en<http://www.ati.es/novatica/lecturas.html>.

Sección Técnica "Interacción Persona-Computador"(Julio Abascal González)

Tema:Tema:Tema:Tema:Tema: Jesús LorésJesús LorésJesús LorésJesús LorésJesús Lorés in memoriam.

El pasado 9 de noviembre falleció el profesor Jesús Lorés i VidalJesús Lorés i VidalJesús Lorés i VidalJesús Lorés i VidalJesús Lorés i Vidal,Catedrático de la Escuela Universitaria de Informática de la Univer-sidad de Lleida, que era corresponsable de la sección de InteracciónPersona-Computador de NováticaNováticaNováticaNováticaNovática.

Jesús LorésJesús LorésJesús LorésJesús LorésJesús Lorés era Ingeniero en Telecomunicaciones por la Universi-dad Politécnica de Cataluña, UPC (1980). En 1994 se doctoró enInformática, también en la UPC, después de haber trabajado en laempresa privada durante algunos años. Fue uno de los promotoresy el primer director de la Escuela de Informática (1990-1993) de laUniversidad de Lleida. Allí fundó el Grupo de Investigación enInteracción Persona-Ordenador y Bases de Datos (GRIHO), conuna muy destacada producción científica en ámbitos tales como laUsabilidad, la Realidad Aumentada y la Accesibilidad. Ademástrabajó intensamente en la mejora de la enseñanza de la InteracciónPersona-Ordenador.

En 1999, convocó a un grupo de profesores con experiencia enInteracción Persona Ordenador procedentes de diversas universida-des españolas para fundar la Asociación de Interacción Persona-Ordenador (AIPO), que presidió, con el apoyo unánime de susmiembros, hasta su muerte. Bajo su dirección AIPO conoció undesarrollo impresionante1, se publicó un libro electrónico que hasido un referente para los docentes de Interacción Persona-Ordena-dor en lengua castellana, se diseñó un curricula que sirve de modelode master en IPO, se creó una sección de profesionales no universi-tarios en la asociación, se organizó una serie anual de congresosinternacionales denominados Interacción2, etc. Su actitud apasio-nada, directa e integradora modeló una asociación abierta a todaslas experiencias, tendencias y puntos de vista. El hueco que deja enla asociación difícilmente podrá ser llenado. Todos los que noshonramos con su amistad admiramos su gran capacidad de trabajo,de entusiasmo y su amor por la naturaleza, la ecología, la lectura y,particularmente, el senderismo. Su pérdida ha significado un durogolpe no sólo para su familia y sus amigos, sino también para eldesarrollo de la Interacción Persona-Ordenador en España.

Jesús, sit tibi terra levis!

1 En la página web de la asociación, www.aipo.es, se puedenconsultar los detalles de las actividades de AIPO.2 En 2000 en Granada, en 2001 en Salamanca, en 2002 en Madrid,en 2003 en Vigo, en 2004 Lleida, en 2005 en Granada 2005, en 2006en Puertollano y en 2007 se celebrará en Zaragoza.

Sección Técnica "Acceso y recuperación de información"(José María Gómez Hidalgo, Manuel J. Maña López)

Tema: Tema: Tema: Tema: Tema: securización de servicios de información en la Web usandosistemas CAPTCHA.

Los buscadores y portales Web como Yahoo!, Google o MicrosoftLive, ofrecen un número creciente de servicios, entre los que seincluyen el correo electrónico, los grupos o listas, la personalizaciónde las búsquedas, etc. La viabilidad de estos servicios depende engran medida de que no sean objeto de abuso, por parte de usuariosmalintencionados que desarrollan sistemas de suscripción masiva a

los mismos, y los utilizan para enviar, por ejemplo, cantidadesingentes de correo basura o spam.

Para evitar los programas o robots de suscripción masiva, los serviciosWeb hacen uso de sistemas CAPTCHA ("Completely AutomatedPublic Turing Test to Tell Computers and Humans Apart"), prueba deTuring completamente automática y pública para separar computadorasy humanos. Estos sistemas, ideados por un equipo de Carnegie Mellondirigido por Luis von Ahn (actualmente en Google), son capaces degenerar pruebas visuales o de sonido que una persona es típicamentecapaz de superar, pero una computadora no. Por ejemplo, los sistemasCAPTCHA visuales generan secuencias de caracteres aleatoriosdistorsionados, que un humano puede identificar con cierta facilidad,pero que presentan numerosos problemas para los sistemas de análisisde imágenes y reconocimiento de caracteres. Estos métodos son aplica-ciones prácticas de la prueba de Turing, una técnica ideada con el fin dedemostrar que una computadora es inteligente comparando su com-portamiento con un ser humano en una conversación con un tercero.

Los sistemas CAPTCHA han sido presentados en [1] y [2], losartículos más citados sobre este tema. Con múltiples aplicacionesanti-spam y de seguridad (véase la página del proyecto en <http://www.captcha.net/>), los sistemas CAPTCHA ya han sido supera-dos en ocasiones (con índices de efectividad del 80%), pero ello noes más que parte de una ecuación ganadora: o bien un sistemaCAPTCHA es superado, para lo cual es preciso lograr avancessignificativos en análisis de imagen (éxito), o bien resiste a losataques, con lo cual es seguro (éxito). En definitiva, éxito o éxito.

[1] L. von Ahn, M. Blum, N.J. Hopper, J. Langford. [1] L. von Ahn, M. Blum, N.J. Hopper, J. Langford. [1] L. von Ahn, M. Blum, N.J. Hopper, J. Langford. [1] L. von Ahn, M. Blum, N.J. Hopper, J. Langford. [1] L. von Ahn, M. Blum, N.J. Hopper, J. Langford. Telling humansand computers apart automatically. Communications of the ACM47 (2), Febrero de 2004, pp. 56-60.[2] L. von Ahn, M. Blum, J. Langford. [2] L. von Ahn, M. Blum, J. Langford. [2] L. von Ahn, M. Blum, J. Langford. [2] L. von Ahn, M. Blum, J. Langford. [2] L. von Ahn, M. Blum, J. Langford. CAPTCHA: Using Hard AIProblems for Security. Advances in Cryptology - EUROCRPYT2003: International Conference on the Theory and Applications ofCryptographic Techniques, Proceedings, LNCS 2656, Springer, pp.294-311. Varsovia, Polonia, 4-8 Mayo de 2003.

Tema:Tema:Tema:Tema:Tema: noticia – Inauguración de los laboratorios de Yahoo! enLatinoamérica.

El día 3 de noviembre de 2006 se ha celebrado la inauguración de loslaboratorios de investigación de Yahoo! en Latinoamérica (Yahoo!Research Latin America, <http://research.yahoo.com/location/yahoo_research_latin_america>), situados en la Universidad de Chile,en Santiago de Chile. Esta nueva sede de investigación se une a las cincoya existentes, tres de ellas en California, una en Nueva York, y otra muyrelevante, en Barcelona. La misión de los investigadores de estoslaboratorios es la de generar los avances científicos que darán lugar a losnuevos negocios de Yahoo! en el futuro, concentrándose en el análisisde grandes cantidades de datos para la mejora de la búsqueda en elmarco de modelos económicos viables. Tanto la sede de Chile como lade Barcelona (también recientemente inaugurada) están dirigidas por elDr. Ricardo Baeza-Yates, investigador con un destacado currículo enRecuperación de Información. Miembro de la Real Academia deCiencias de Chile, es autor de dos de los libros de referencia básicos enel ámbito de la Recuperación de Información, y de numerosas publica-ciones científicas en este tema. En los últimos tiempos, su investigaciónha estado dirigida a la minería de datos para la mejora de la búsquedade información en la Web.

Según recientes comentarios del Dr. Baeza-Yates en el PrimerSeminario de la red de investigación MAVIR <http://www.mavir.net>, el modelo de relación investigación-negocio en Googley en Yahoo! es sustancialmente distinto. En Google se apuestaporque los trabajadores combinen sus labores de investigación, dedesarrollo y de negocio. En cambio, en Yahoo! se sigue un modelo

novática nº 184 noviembre-diciembre 200664 secciones técnicas

refe

renc

ias

auto

rizad

as

más tradicional en el que los investigadores están relativamentedesvinculados del área de negocio, a la que proveen de ideasevaluadas en laboratorio, para que en dicha área de proceda a suevaluación en entornos reales, y de ser posible, a su transformaciónen productos o en características de productos existentes. Dosmodelos opuestos, pero ambos exitosos.

Tema:Tema:Tema:Tema:Tema: libro.

Ian H. Witten, Eibe Frank.Ian H. Witten, Eibe Frank.Ian H. Witten, Eibe Frank.Ian H. Witten, Eibe Frank.Ian H. Witten, Eibe Frank. Data Mining: Practical Machine LearningTools and Techniques (Second Edition). Morgan Kaufmann, ISBN0-12-088407-0, 2005. Estamos ante la segunda edición de un libroque ya tuvo mucho éxito en su primera edición del año 1999. El libroaborda la aplicación del aprendizaje automático a la minería dedatos desde una perspectiva eminentemente práctica. La intenciónde los autores no sólo ha sido escribir un libro de texto, sino tambiénconseguir que sea de utilidad a los profesionales que desean aplicarla minería de datos a problemas reales. La utilización de un lenguajeclaro, la motivación práctica y la huida del formalismo excesivopermite a los autores conseguir ambos objetivos al mismo tiempo. Ellibro viene acompañado, además, por WEKA, una herramientagratuita que lo hace aún más valioso. WEKA (Waikato Environmentfor Knowledge Analysis, véase <http://www.cs.waikato.ac.nz/~ml/weka>) implementa en Java los algoritmos de aprendizaje descritosen el libro. Estos algoritmos se pueden utilizar directamente sobrelos datos a través de la interfaz que se proporciona o llamándolosdesde nuestro código Java. El texto se estructura en dos partes. En laprimera, se presentan los algoritmos de aprendizaje más importantes ylos conceptos fundamentales de la minería de datos. Respecto a laedición anterior, los autores han introducido cambios con el objeto decubrir más esquemas de aprendizajes, incluir la evaluación en funcióndel coste y añadir nuevas aplicaciones, como la minería de textos, laminería de la Web o la minería de datos ubicuos. La segunda parte seocupa de explicar cómo usar Weka, tanto desde la interfaz como desdeotros programas Java. Esta es la parte que más ha cambiado en estanueva edición, incorporando nuevos capítulos. En total, la segundaedición incluye más de 100 nuevas páginas respecto a la edición anterior.

Tema: Tema: Tema: Tema: Tema: noticia – Buscador España I+D+I. Un nuevo buscadorespecializado en ciencia y tecnología.

El pasado 13 de noviembre se presentó el nuevo buscador EspañaI+D+I de Madri+d. Se trata de un buscador temático que permiteacceder a la información de más de 300 centros de investigación,organismos públicos, empresas innovadoras y portales especializa-dos. Otra característica importante de este buscador es que presentalos resultados de la búsqueda clasificados según una jerarquía decategorías predefinidas, para lo cual utiliza técnicas de ingenieríalingüística. Así en el primer nivel de esa jerarquía encontramoscategorías como: Ciencias Biológicas, Ciencias de la Salud, Energíao Industria y Tecnología. El buscador permite también la búsquedade frases y la utilización de operadores lógicos. Para los organismosque forman parte del Sistema Madri+d, el buscador permite ademásseleccionar el tipo de información que se desea, como noticias,proyectos de investigación, empresas, ofertas de empleo o convoca-torias de fuentes oficiales. El buscador está disponible en <http://buscador.madrimasd.org>.

Sección Técnica "Arquitecturas"(Enrique F. Torres Moreno, Jordi Tubella Morgadas)

Tema: Tema: Tema: Tema: Tema: libro

William Stallings. William Stallings. William Stallings. William Stallings. William Stallings. Organización y arquitectura de computadoras.Pearson Prentice Hall, 2006. ISBN: 8489660824, 800 páginas. En elcatalogo universitario de esta famosa editorial ha aparecido

recientemente como novedad la versión en castellano de la séptimaedición de este conocido libro (Computer Organization AndArchitecture: Designing For Performance). La revisión técnica hasido realizada por Alberto Prieto, miembro del departamento deArquitectura y Tecnología de Computadores de la Universidad deGranada. Si bien aun no hemos tenido la oportunidad de ojear estaversión en castellano, si que conocemos la versión en inglés y sucompletísima pagina web de acompañamiento <http://illiamstallings.com/COA/COA7e.html>.

Para el profesorado, en la pagina web, podemos encontrar tanto lasfiguras, tablas y notas en pdf como las transparencias de los temas enformato powerpoint. Para los alumnos encontraremos diversos enla-ces, ordenados por capítulos, e información suplementaria. Respecto aesta nueva edición decir que se trata de una versión actualizada, quesigue dividida en cinco partes: visión general, sistemas de computadoras,unidad central de proceso, la unidad de control y organización paralela,pero que ha sido ampliamente actualizada.

El libro esta dirigido principalmente al mundo académico universitariocomo libro de texto en todas las ingenierías, principalmente en Informá-tica en los niveles técnicos y superiores. Para los profesionales interesa-dos en este tema, el libro les podría servir como guía de referencia básicae incluso como libro de auto aprendizaje.

Sección Técnica "Auditoría SITIC"(Marina Touriño Troitiño, Manuel Palao García-Suelto)

Tema: Tema: Tema: Tema: Tema: COBIT y las normas de la Comunidad Europea. Referencia:ASITIC- 028 – COBIT y la CE –MTT.

Las "buenas prácticas" o "esquema" para el gobierno de las Tecno-logías de la Información (TI) que constituyen COBIT (ControlObjectives for Information and Related Technology2) suele a vecesconfundirse con los aspectos de seguridad de las TI. Aunque ladifusión de la normativa COBIT, es bastante significativa entre losprofesionales de las TI, ésta es aún bastante desconocida en cuantoa su alcance y a su aplicación práctica.

COBIT se asimila erróneamente, en algunos casos, a una metodolo-gía de auditoría de sistemas de información / TI, hasta el extremo deconsiderarlo un esquema equivalente a normas o directrices deseguridad. Sin embargo COBIT está enfocado al gobierno de TI, que,entre otras actividades, incluye la gestión de la seguridad. Así,aunque tienen aspectos en común: el análisis y gestión de riesgosrequerido, la mejora continua, la monitorización, el seguimiento, ysimilares, el alcance de COBIT es mucho más amplio que puramentelas normas de seguridad.

Una prueba más de esta confusión, pero al mismo tiempo delreconocimiento que va logrando mundialmente, es el Reglamento(CE) No 465/2005 de la Comisión de las Comunidades Europeas de22 de marzo de 2005, publicado en el Diario Oficial de la UniónEuropea, el 23 de marzo de 2005. Este Reglamento modifica elReglamento (CE) no 1663/95.

Este Reglamento aplicable a los organismos pagadores (dentro delámbito del FEOGA), indica que: "La seguridad de los sistemas deinformación estará basada en los criterios fijados en una versiónaplicable en el ejercicio considerado de una de las siguientes normasaceptadas internacionalmente:

Organización Internacional de Normalización 17799/Norma bri-tánica 7799: Code of practice for Information Security Management(Código de prácticas para la gestión de la seguridad de la informa-ción) (BS ISO/IEC 17799).

Bundesamt für Sicherheit in der Informationstechnik: IT-

novática nº 184 noviembre-diciembre 2006 65secciones técnicas

refe

renc

ias

auto

rizad

as

Grundschutzhandbuch (Manual de protección informática de base)(BSI).

Information Systems Audit and Control Foundation: ControlObjectives for Information and related Technology (Objetivos decontrol para la información y tecnologías afines) (COBIT).

El organismo pagador elegirá una de las normas internacionalesindicadas en el primer párrafo como referencia para las medidas de para las medidas de para las medidas de para las medidas de para las medidas deseguridad de sus sistemas de informaciónseguridad de sus sistemas de informaciónseguridad de sus sistemas de informaciónseguridad de sus sistemas de informaciónseguridad de sus sistemas de información.

Las medidas de seguridad deberán estar adaptadas a la estructuraadministrativa, al personal y al entorno tecnológico de cada organis-mo pagador. El esfuerzo financiero y tecnológico deberá ser propor-cional a los riesgos reales".

De la lectura de este párrafo, se desprenden dos reflexiones:1. Que los organismos públicos están reconociendo cada vez más laimportancia de la seguridad de la información (integridad,confidencialidad y disponibilidad), en la gestión de sus propiosprocesos de TI, y por ende en la necesidad de un buen gobierno deestos recursos que son cada vez más críticos.2. Que está muy difundida la confusión mencionada anteriormenteen cuanto a equiparar la norma ISO 17799, con COBIT.

COBIT 4 es una herramienta crítica que abarca la gestión integral degestión integral degestión integral degestión integral degestión integral deTITITITITI. Por lo tanto, la aplicación de COBIT podría tomarse como elpunto de partida integral y global para el gobierno de las TI, e irsumando las buenas prácticas y esquemas de las otras normasespecíficas (ISO 27001 para la gestión de la seguridad, ITIL, etc.).La razón fundamental para esta referencia en relación al Reglamen-to mencionado es destacar la importancia que se está reconociendoa COBIT, , , , , al punto de incluirse en una regulación de este nivel.

Es de esperar que un futuro cercano, los profesionales de las TI, losauditores y consultores de TI, divulguen con más precisión el verdaderoalcance de COBIT, así como su complementariedad y compatibilidadcon otras normas de seguridad, así como también su aspecto distintivoen relación al gobierno de las TI. El Information Technology GovernanceInstitute publicó recientemente (16 de diciembre) la edición 4.0 deCOBIT <www.itgi.org>, <www.isaca.org>.

Sección Técnica "Derecho y Tecnologías"(Elena Davara Fernández de Marcos)

Tema:Tema:Tema:Tema:Tema: la APDCM traduce al castellano la Guía PRIME.

La Agencia de Protección de Datos de la Comunidad de Madrid(APCM) ha traducido al castellano la Guía PRIME (acrónimo delinglés Privacy and Identity Management in Europe). Esta Guía es unproyecto europeo que busca nuevas soluciones de privacidad en lagestión electrónica de la identidad de las personas. La Guía PRIMEtiene por objeto analizar los conceptos relacionados con la identifi-cación de las personas, primero en el mundo físico o "fuera de línea"(off line), y posteriormente en el mundo digital (on line). En estesentido, se presta atención a cuestiones tales como la identificabilidad,la traza de datos o el uso de identidades parciales, así como asistemas existentes de gestión de la identidad. Con los sistemas degestión de la identidad (GID) se busca que el usuario pueda utilizary gestionar diferentes identidades parciales digitales, de manera quepueda decidir en cada contexto qué identidad utiliza. Estos sistemaspermiten, en definitiva, que el usuario pueda controlar el tratamientoque se hace de sus datos de carácter personal, pudiendo citarse amodo de ejemplo Microsoft NET Passport, Liberty Alliance, MozillaNavigator y Outlook Express. Además, se describen las característi-cas deseables de un GID centrado en el usuario y basado en lamáxima privacidad posible (el sistema PRIME). La APDCM se

incorporó al Grupo de Referencia del proyecto PRIME en marzo de2006. El objeto de este proyecto es avanzar el estado del arte en lascaracterísticas de privacidad de la gestión de la identidad, y mostrarcómo se puede conjugar el uso de las Tecnologías de la Informacióny las Comunicaciones y el necesario respeto del derecho fundamen-tal a la protección de datos de carácter personal de los ciudadanos.Más información en: <http://blues.inf.tu-dresden.de/prime/EUT_Tutorial_V0/spanish/PRIME_fs.htm>.

Tema: Tema: Tema: Tema: Tema: adaptación del sistema CIFRADOC a la firma electrónicareconocida.

En el Boletín Oficial del Estado número 257, de 27 de octubre, se hapublicado el acuerdo de 15 de septiembre, del Consejo de la Comi-sión Nacional del Mercado de Valores (en adelante, CNMV), enrelación con la adaptación del Sistema CIFRADOC/CNMV a losservicios de certificación y firma electrónica reconocida y por el quese crea el Registro Telemático de la CNMV. En cuanto al SistemaCIFRADOC/CNMV, cabe señalar que fue creado con caráctertransitorio, habiendo permitido éste implementar en la CNMV unsistema de cifrado y firma electrónica basado en los principios deautenticidad, confidencialidad y conservación, entre otros. Además,desde 1998 el citado sistema había facilitado que un grupo cerradode entidades que se encontraban sujetas a la supervisión de laCNMV pudieran recibir y registrar documentos electrónicos endicho ámbito, lo que suponía un claro ejemplo y desarrollo deAdministración electrónica. Los cambios que se introducen ahoraen el sistema se deben a la publicación de la Ley 59/2003, de 19 dediciembre, de Firma electrónica, entre otras, de manera que seestablece un nuevo régimen jurídico para la regulación de loscriterios generales que deben inspirar la presentación telemática ytramitación posterior con firma electrónica reconocida de escritos,solicitudes y comunicaciones cuya resolución o recepción competea la CNMV. Por último, se crea un Registro Telemático al que seencomienda la llevanza y recepción de escritos, solicitudes y comu-nicaciones que se remitan por vía telemática mediante el uso de lafirma electrónica reconocida, que es la firma electrónica avanzadabasada en un certificado reconocido y generada mediante un dispo-sitivo seguro de creación de firma. Más información en: <http://www.boe.es/boe/dias/2006/10/27/pdfs/A37484-37487.pdf >.

Tema:Tema:Tema:Tema:Tema: creada la Comisión de Administración-e en el Ministerio deHacienda.

En el Boletín Oficial del Estado número 274, de 16 de noviembre, seha publicado la Orden EHA/3507/2006, de 8 de noviembre, por laque se regula la composición y funciones de la Comisión Ministerialde Administración Electrónica del Ministerio de Economía y Ha-cienda. La Comisión que se crea es el órgano colegiado del Minis-terio de Economía y Hacienda responsable de la coordinación enmateria de tecnologías de la información y de Administraciónelectrónica, siendo además el enlace con el Consejo Superior deAdministración Electrónica, su Comisión Permanente y sus gruposde trabajo. Por lo que se refiere a las funciones de esta Comisión,desempeñará, entre otras, las relativas a elaborar el proyecto del planestratégico del Departamento en materia de tecnologías de la infor-mación y Administración electrónica; coordinar las actuacionesdirigidas a establecer líneas estratégicas y criterios técnicos deinterés común en materia de tecnologías de la información y Admi-nistración electrónica así como estudiar la normalización tecnológi-ca y su implantación en orden a asegurar la compatibilidad de lossistemas y el intercambio de los datos. En concreto, las funciones dela Comisión se agrupan atendiendo a que se trate de funciones decoordinación departamental en materia de tecnologías de la infor-mación y Administración electrónica, funciones de relación y coor-dinación con el Consejo Superior de Administración Electrónica,funciones de impulso de la Administración electrónica, funciones de

novática nº 184 noviembre-diciembre 200666 secciones técnicas

refe

renc

ias

auto

rizad

as

asesoramiento en materia de tecnologías de la información y funcio-nes en materia de contratación de tecnologías de la información. Porúltimo, cabe señalar que la Comisión podrá actuar en Pleno y enComisión Permanente, además de que, por razones de urgencia o deeficacia, la Comisión Permanente podrá actuar a través de Gruposde trabajo específicos, permanentes o no, que actuarán bajo lasuperior dirección del Presidente de la Comisión Permanente. Másinformación en: <http://www.boe.es/boe/dias/2006/11/16/pdfs/A40083-40087.pdf>.

Tema: Tema: Tema: Tema: Tema: constitución de Sociedades de Responsabilidad Limitada porInternet.

El Ministerio de Industria, Turismo y Comercio y el Ministerio deJusticia han elaborado un proyecto de Real Decreto en virtud delcual se podrán constituir Sociedades de Responsabilidad Limitada(SRL) a través de Internet. El Real Decreto podría entrar en vigor aprincipios del próximo año. En cuanto a la constitución de socieda-des a través de Internet, hasta el momento sólo puede producirse enel caso de la Sociedad Limitada Nueva Empresa. En concreto, esnecesario atender a las previsiones contenidas en la Ley 7/2003, de1 de abril, de la Sociedad Limitada Nueva Empresa. Con lapromulgación del Real Decreto, las SRL podrán hacer uso de la redde 150 oficinas que existen actualmente para la tramitación de lasgestiones necesarias, y que se denominan PAIT´s (siglas de Puntosde Asesoramiento e Inicio de Tramitación). En concreto, quienesvayan a constituir una SRL sólo tendrán que acudir a un PAIT y alnotario que elijan para el otorgamiento de la escritura pública de lasociedad, evitando así tener que desplazarse para tener que realizartodos los trámites y cumplimentar varios formularios en papel. Deesta manera, la empresa con forma societaria se constituirá con baseen el Documento Único Electrónico (DUE), simplificando todos lostrámites necesarios y ahorrando a los emprendedores mucho tiempoya que el DUE sustituye a los quince formularios que existenactualmente. Es necesario tener en consideración que la SRL es laforma societaria más utilizada en el mundo empresarial, y la existen-cia de obstáculos a su creación puede suponer un freno para lasmismas. En definitiva, se trata de que puedan constituirse SRL deigual forma que puede hacerse en el caso de la Sociedad LimitadaNueva Empresa. Más información en: <http://www.la-moncloa.es/Conse jodeMinis t ros/Referenc ias /_2006/re fc20061117.htm#SociedadesInternet>.

Tema: Tema: Tema: Tema: Tema: informe de la OMPI sobre patentes 2006.

La Organización Mundial de la Propiedad Intelectual (OMPI) hapublicado un informe sobre patentes (2006). En dicho informe sepone de manifiesto el carácter internacional que están adquiriendolas patentes y que éstas son cada vez más utilizadas por la empresaspara proteger sus inversiones en los nuevos mercados. En cuanto alas cifras, las más recientes son las de 2004, pero indican que ya enese año había 5,4 millones de patentes en todo el mundo. Cabeseñalar que el número de solicitudes de patentes se ha duplicadoentre 1985 y 2004, pasando de 884.400 a 1.599.000, con un incre-mento anual medio del 4,75% desde 1995. A pesar del aumento desolicitudes de patentes en países con economías incipientes y derápido desarrollo, éstas se siguen concentrando en cinco oficinas enlas que se origina el 75% de todas las solicitudes presentadas yel 74% de las patentes concedidas en todo el mundo. Son lasoficinas de Estados Unidos (EE.UU.), Japón, la Oficina Europea dePatentes (OEP) y las oficinas de la República de Corea y de China.No obstante, EE.UU. y Japón se sitúan a la cabeza de las solicitudesde patentes. De los 5,4 millones de patentes que se habían concedidoen 2004 en todo el mundo, el 81% se repartían entre seis países:EE.UU., Japón, Reino Unido, Alemania, la República de Corea yFrancia. De las patentes que se encontraban en vigor en 2004, el 53%había sido solicitado en 1997 o con posterioridad y el 22% eran

solicitudes anteriores a 1994. Por último, cabe señalar que en elinforme se maneja el concepto del indicador de intensidad depatentamiento, que establece la relación entre el número de patentesy los distintos indicadores del tamaño de un país (población,producto interior bruto –PIB-, gasto en investigación y desarrollo).Más información en: <http://www.wipo.int/ipstats/en/statistics/patents>.

Tema: Tema: Tema: Tema: Tema: informe sobre la utilización de las TIC en España en 2006.

Se ha presentado un informe en el Consejo de Ministros analizandolas actuaciones llevadas a cabo por el Ministerio de Industria paraimpulsar la utilización de las TIC en tres ámbitos: ciudadanos,empresas y e-administración. Por lo que respecta a la ciudadanía, enabril de 2005 se creó la Oficina de Atención al Usuario de Telecomu-nicaciones, que ha atendido 216 consultas al día en 2006, un 7,4%más que en 2005 mientras que el número de reclamaciones se haelevado a 1.300 al mes, un 20,3% más. En el ámbito empresarial seincluyen una serie de medidas de soporte a las PYMES, entre otras:préstamos a PYMES en condiciones preferenciales para la inversiónen TIC o los sistemas de información, así como los portales PYMEy CIRCE, creados por el Ministerio en 2005, ofreciendo informacióny herramientas interactivas para la mejora de la gestión de lasPYMES. Las iniciativas del Ministerio de Industria en lo referente ala e-administración son variadas, destacando Justicia y Sanidad enRed y el Plan Ayud@tec. Más información en: <http://www.la-moncloa.es/ConsejodeMinistros/Referencias/_2006/refc20061027.htm#Tecnologías>.

Sección Técnica "Enseñanza Universitaria de la Informática"(Joaquín Ezpeleta Mateo, Cristóbal Pareja Flores)

Tema:Tema:Tema:Tema:Tema: "Los otros" (concursos de programación).

En efecto: hay otros concursos de programación aparte delarchiconocido de la ACM y que, por cierto, comentamos en estamisma sección en el número 148 (noviembre-diciembre de 2000).Uno de esos "otros" es la International Olympiad in Informatics(IOI), el concurso de programación más importante del mundo paraestudiantes no universitarios. La clase de problemas que se planteanpresenta sobre todo una dificultad de naturaleza algorítmica, perolos concursantes deben demostrar además habilidades de análisis deproblemas, diseño de algoritmos y estructuras de datos, así como deprogramación y comprobación de sus soluciones. La IOI naciócomo una propuesta del profesor búlgaro Sendov en la vigésimocuarta conferencia de la UNESCO, en París, en 1987. Dos añosdespués se celebró la primera IOI, que tuvo lugar en Bulgaria en 1989con el apoyo de la UNESCO, y desde entonces viene celebrándoseanualmente en distintas ciudades del mundo. Aún no ha tenidonunca lugar en España, por cierto.

Los lenguajes de programación oficiales son C/C++ y Pascal. Se haconsiderado recientemente Java pero actualmente no está incluido.Tampoco Microsoft Windows está disponible en los equipos paralos concursantes. Su página oficial es la siguiente: <http://www.ioinformatics.org/>.

Otro de los "otros" es el concurso de desarrollo de aplicaciones enJavaTM de Ricoh & Sun, dirigido a estudiantes universitarios y deámbito europeo. En este caso, la dificultad principal no es denaturaleza algorítmica, sino que el énfasis está en el desarrollo deaplicaciones de negocios o juegos. El concurso se desarrolla en doseliminatorias internas en los distintos países, y una entre los equiposvencedores en cada país de Europa. En el momento de recibirse estapublicación estará cerrado el plazo de inscripción para la tercera edición(2007), pero aún estaremos a tiempo de conectarnos a la página oficial

novática nº 184 noviembre-diciembre 2006 67secciones técnicas

refe

renc

ias

auto

rizad

as

<https://ricoh.dev.java.net/>, donde se anunciará oportunamente elde 2008.

El penúltimo "otro" es el ICFP Programming Contest, que vienecelebrándose anualmente desde 1998, bajo los auspicios del Internacio-nal Conference on Functional Programming (ICFP). El primer año, elnombre del concurso llevaba la coletilla "funcional", quizá para resaltarla inclusión de este modelo de programación entre los lenguajes oficia-les. Desde el segundo año, el nombre no alude a ningún paradigmaconcreto, y nosotros creemos que esta integración de la diversidad esposiblemente el valor más importante de este concurso; de hecho, seusan lenguajes como C++ y Java por supuesto, pero también Pyton,Perl y Haskell. Yo tenía curiosidad por saber en qué lenguajes progra-maron sus soluciones los ganadores de las últimas ediciones. ¿Queréissaberlo vosotros? Yo lo hice, mirando en la página <http://www.cs.cornell.edu/icfp/> y subsecuentes.

Para terminar, comentamos el poco convencional InternacionalObfuscated C Code Contest (visítese <http://www.es.ioccc.org/>),que trata sobre las oscuras artes de programar de manera críptica odesconcertante, pero que no por ello es este concurso menos nobleque los anteriores, y que incluso persigue objetivos nobles (como esresaltar la importancia de un buen estilo de programación), si biende un modo irónico. No hemos podido resistir la tentación decopiaros un programa:

Posiblemente no se entienda bien debido al reducido tamaño de laletra, pero en la dirección <http://www.es.ioccc.org/1989/roemer.c>está este texto disponible, para los más atrevidos.

Sección Técnica "Entorno Digital Personal"(Alonso Alvarez García, Diego Gachet Páez)

Tema: Tema: Tema: Tema: Tema: conferencia.

Con el auspicio de la IEEE EMB Society (Engineering in Medicineand Biology) y la ACM se realizó en Innsbruck, Austria entre el 27de Noviembre y el 2 de Diciembre la primera edición de la conferen-cia internacional "Pervasive Computing Technologies for Healthcare2006" <http://www.pervasivehealth.org/>. Las actividades de laconferencia se desarrollaron alrededor de varias sesiones dedicadasa "Tecnologías situadas en el paciente", "Tecnologías para mejorarla salud de las personas", "Computación móvil como soporte para eltrabajo en hospitales", "Monitorización de pacientes", etc. Además,en conjunto con la conferencia se organizaron dos workshops muyinteresantes, PMHCS (privacy and security in mobile healthcare)

que trató sobre aspectos de seguridad en aplicaciones móviles parael sector de salud y LOCARE (location based services for healthcare,<http://www.locare.org>) dedicada a las tecnologías y aplicacio-nes de la geolocalización en salud, esta última estuvo muy interesan-te y contó con la presencia de Jeffrey Hightower del Intel ResearchLab, que nos habló sobre las tecnologías para localización enexteriores e interiores y las posibilidades futuras de nuevos serviciosen el sector salud basados en ellas.

Sección Técnica "Gestión del Conocimiento"(Joan Baiget Solé)

Tema: Tema: Tema: Tema: Tema: libro.

Manuel Riesco Gonzalez.Manuel Riesco Gonzalez.Manuel Riesco Gonzalez.Manuel Riesco Gonzalez.Manuel Riesco Gonzalez. El Negocio es el Conocimiento. Ed. Diaz deSantos, 280 páginas. Manuel Riesco es doctor en Sociología, especia-lizado en Dirección y Gestión de Personas. El libro presenta un primerapartado denominado: "Un nuevo escenario para los negocios", dondecentra el tema de la Sociedad de la Información y el Conocimiento. Enla segunda parte, llamada "El diamante de la Gestión del Conocimien-to", introduce el concepto y sus relaciones con la tecnología. Finalmente,en la tercera parte, "De los Modelos a los Proyectos de Gestión delConocimiento", hace un detallado repaso de los distintos modelos degestión del conocimiento existentes, para acabar proponiendo un mo-delo propio: el MIS o Modelo Integrado Situacional. El cuarto aparta-do es de "Conclusiones". ¿Y ahora, qué?

Sección Técnica "Informática Gráfica"(Miguel Chover Sellés, Roberto Vivó Hernando)

Tema:Tema:Tema:Tema:Tema: nuevo estándar y libro.

Durante más de 40 años, se han desarrollado un gran número deformatos de intercambio de información tridimensional. Cada nuevoprograma de modelado geométrico define su propio formato para larepresentación de escenas y debe dar soporte a la importación de datosdesde otros formatos propietarios. Esto supone uno de los problemasclásicos del desarrollo de software que plantea la necesidad de un nuevoformato común. Finalmente, gracias al impulso de una de las empresasmás importantes en la creación de contenidos digitales Sony ComputerEntertainment se ha desarrollado COLLADA.

COLLADA es el primer estándar de intercambio de contenidos digitalesdesarrollado por la industria de los videojuegos, las aplicaciones dediseño asistido por ordenador y los fabricantes de hardware gráfico.Este nuevo estándar basado en XML permite la transferencia deinformación 3D entre diferentes plataformas: modelos 3D, vértices,polígonos, texturas, shaders, transformaciones, luces, cámaras, etc.Más aún, es un formato extensible que permitirá la incorporación denuevas características 3D a medida que se produzca la evolución en estecampo. En la actualidad existen un gran número de compañías adheri-das al proyecto, siendo adoptado como estándar industrial por el grupoKhronos (asociación que también da soporte por ejemplo a OpenGL)en enero de 2006. Ya existen muchas aplicaciones tanto comercialescomo no comerciales que lo soportan y empieza a ser utilizado habitual-mente por los programadores.

Como libro de consulta sobre este estándar:Rémi Arnaud y Mark C. Barnes.Rémi Arnaud y Mark C. Barnes.Rémi Arnaud y Mark C. Barnes.Rémi Arnaud y Mark C. Barnes.Rémi Arnaud y Mark C. Barnes. COLLADA: Sailing the Gulf of 3DDigital Content Creation. Ed. A K Peters, Ltd. 2006. ISBN: 1-56881-287-6. El libro es una excelente primera toma de contacto con elestándar, abordándolo desde una perspectiva práctica. Escrito porlos creadores de COLLADA, además de exponer sus orígenes y losmotivos por los que se ha desarrollado, enfatiza los beneficios quepueden derivarse de su utilización. Este tipo de iniciativa reducirá los

novática nº 184 noviembre-diciembre 200668 secciones técnicas

refe

renc

ias

auto

rizad

as

tiempos y el coste de la creación de contenidos digitales, así como surápida extensión. Más información relacionada con COLLADA en:http://www. collada.org/>, <http://www.khronos.org/>.

Sección Técnica "Ingeniería del Software"(Javier Dolado Cosín, Luis Fernández Sanz)

Tema: Tema: Tema: Tema: Tema: libros.

U.S. Food and Drug Administration (FDA).U.S. Food and Drug Administration (FDA).U.S. Food and Drug Administration (FDA).U.S. Food and Drug Administration (FDA).U.S. Food and Drug Administration (FDA). General Principles ofSoftware Validation; Final Guidance for Industry and FDA Staff.<http://www.fda.gov/cdrh/comp/guidance/938.html>. Una inte-resante guía que la FDA (Food and Drug Agency) de EE.UU.considera aplicable para la validación de software claramente crítico(relacionado con medicina y, por tanto, con vidas humanas). Puederesultar una guía interesante para ser aplicada a otros proyectoscríticos o simplemente como lista de ideas para otros tipos desoftware sin ese carácter crítico en los que se eliminarán o matizaránalgunas de las exigencias de control expresadas en este documento.

Ivica Crnkovic y Magnus Larsson (eds.).Ivica Crnkovic y Magnus Larsson (eds.).Ivica Crnkovic y Magnus Larsson (eds.).Ivica Crnkovic y Magnus Larsson (eds.).Ivica Crnkovic y Magnus Larsson (eds.). Building ReliableComponent-Based Software Systems, Artech House, 2002. La webde este libro editado por Ivica Crnkovic y Magnus Larsson tiene laventaja de incluir material gratuito para descargar: un informeextendido (12 MB) sobre diversos aspectos del desarrollo de siste-mas software basados en componentes que sean fiables así comobastantes presentaciones Powerpoint sobre los distintos temas tra-tados en el libro. Podemos reseñar el tratamiento de las pruebas y laverificación y validación en este tipo de software. <http://www.idt.mdh.se/cbse-book/>.

Sección Técnica: "Lingüística computacional"(Xavier Gómez Guinovart, Manuel Palomar)

Tema: Tema: Tema: Tema: Tema: manual de procesamiento de la lengua y del habla.

John Coleman. John Coleman. John Coleman. John Coleman. John Coleman. Introducing Speech and Language Processing.Cambridge University Press, Cambridge, 2005. ISBN 0-521-53069-5. Manual de procesamiento del lenguaje natural (PLN) de nivelintroductorio y fuerte orientación práctica, dirigido a un público denivel universitario con ciertos fundamentos de lingüística, pero sinformación específica en el campo de la programación informática nien el de las tecnologías del lenguaje. Los contenidos del libro secentran en dos ámbitos del PLN relacionados con el análisis lingüís-tico: el procesamiento de la señal sonora para el reconocimiento delhabla, y el procesamiento estadístico del lenguaje en los nivelesmorfológico y sintáctico. Tras un capítulo introductorio breve (cap.1), los capítulos 2-4 presentan diversas técnicas de procesado de laseñal sonora: generación de una onda senoidal (cap. 2), filtradodigital (cap. 4), análisis espectral y predicción lineal (cap. 5). Elcapítulo 5 se centra en el funcionamiento de los autómatas deestados finitos y en su aplicación al procesamiento sintáctico yfonológico. En el capítulo 6 se muestran algunas técnicas básicas dereconocimiento del habla, analizando con más detalle la técnica dealineación temporal dinámica. El capítulo 7 presenta los modelosprobabilísticos basados en estados finitos y su uso en el etiquetadomorfosintáctico y en el modelado acústico. En el capítulo 8 seexaminan algunos métodos simples para analizar automáticamentela estructura sintáctica de las frases. Finalmente, en el capítulo 9 seexpone el concepto de gramática probabilística y se ofrecen algunasposibles aplicaciones de este modelo al análisis sintáctico. En todoslos capítulos de este volumen, la exposición de los temas se ilustracon una enorme variedad de ejemplos de aplicaciones concretasimplementadas en C (para el procesamiento de señal) o en Prolog(para los automátas y las gramáticas).

Todos los programas utilizados como ejemplos están recogidos enun CD-ROM que se distribuye con el libro, que incluye también uncompilador de C (DJGPP) y un intérprete de Prolog (SWI-Prolog)con vistas a facilitar su uso. Así mismo, cada vez que se utiliza unprograma como ejemplo en el libro, y antes de proponer su ejecucióny la comprobación de sus resultados, el autor explica con tododetalle y con gran didáctica su código fuente, de manera que éstepueda ser entendido, e incluso modificado, como parte del procesode (auto)aprendizaje de las materias estudiadas.

En suma, el manual de Coleman constituye una aportación muyinteresante a la bibliografía reciente sobre PLN. Su lectura debe serrecomendada como texto introductorio en cursos académicos sobreprocesamiento del habla de nivel universitario. Para más informa-ción y su adquisición en <http://uk.cambridge.org/catalogue/catalogue.asp?isbn=0521530695>.

Sección técnica: "Seguridad"(Javier Areitio Bertolín, Javier López Muñoz)

Tema:Tema:Tema:Tema:Tema: libros.

R. Bejtlich.R. Bejtlich.R. Bejtlich.R. Bejtlich.R. Bejtlich. Extrusion Detection. Security Monitoring for InternalIntrusions. Addison-Wesley. ISBN 0321349962, 2006.B. Caswell, J. Beale, A.R. Baker. B. Caswell, J. Beale, A.R. Baker. B. Caswell, J. Beale, A.R. Baker. B. Caswell, J. Beale, A.R. Baker. B. Caswell, J. Beale, A.R. Baker. Snort Intrusion Detection andPrevention Toolkit. Syngress Publishing. 1st Edition. ISBN1597490997, 2007.H. Delfs, H. Knebl.H. Delfs, H. Knebl.H. Delfs, H. Knebl.H. Delfs, H. Knebl.H. Delfs, H. Knebl. Introduction to Cryptography: Principles andApplications. Springer. 2nd Edition. ISBN 3540492437, 2007.D.F. Ferraiolo, D.R. Kuhn, R. Chandramouli.D.F. Ferraiolo, D.R. Kuhn, R. Chandramouli.D.F. Ferraiolo, D.R. Kuhn, R. Chandramouli.D.F. Ferraiolo, D.R. Kuhn, R. Chandramouli.D.F. Ferraiolo, D.R. Kuhn, R. Chandramouli. Role-Based AccessControl. Artech House Publishers. 2nd Edition. ISBN 1596931132,2007.B.A. ForouzanB.A. ForouzanB.A. ForouzanB.A. ForouzanB.A. Forouzan. Network Security. McGraw-Hill. 1st Edition. ISBN0073327530, 2007.A.Khan. A.Khan. A.Khan. A.Khan. A.Khan. Security Simplified: Computer Internet Protection. KhanConsulting and Publishing, LLC. 1st Edition. ISBN 0977283860, 2007.A.J. Sammes, B. Jenkinson.A.J. Sammes, B. Jenkinson.A.J. Sammes, B. Jenkinson.A.J. Sammes, B. Jenkinson.A.J. Sammes, B. Jenkinson. Forensic Computing. Springer. 2ndEdition. ISBN 1846283973, 2007.M.S. Smith, B.G. Kutais.M.S. Smith, B.G. Kutais.M.S. Smith, B.G. Kutais.M.S. Smith, B.G. Kutais.M.S. Smith, B.G. Kutais. Spam and Internet Privacy. Nova SciencePub. Inc. ISBN 1594545774, 2007.

Tema:Tema:Tema:Tema:Tema: congresos y simposiums.

28th IEEE Symposium on Security and Privacy. Del 20 al 23 deFebrero 2007. The Claremont Resort. Berkley. Oakland. California.USA.10th Information Security Conference (ISC’2007). Del 9 al 12 deOctubre del 2007. Universidad Técnica Federico Santa María.Valparaíso. Chile.8th Annual CERIAS Information Security Symposium’ 2007. Del20 al 21 de Marzo. 2007 Purdue University. Indiana. USA.Northwest Security Symposium (NWSEC’2007). Del 15 al 16 deFebrero. 2007. Carwein UWT (University Washington, Tacoma).USA.Spie Defense and Security Symposium’ 2007. Del 9 al 13 de Abril.2007. Orlando. USA.

Sección técnica: "Tecnología Orientada a Objetos"(Jesús García Molina, Gustavo Rossi)

Tema: Tema: Tema: Tema: Tema: libro.

Alan Shalloway, James Trott. Alan Shalloway, James Trott. Alan Shalloway, James Trott. Alan Shalloway, James Trott. Alan Shalloway, James Trott. Design Patterns Explained: A NewPerspective on Object-Oriented Design, Addison Wesley 2004. A pesarde su título este no es un libro más sobre patrones de diseño. Es un buen

novática nº 184 noviembre-diciembre 2006 69secciones técnicas

refe

renc

ias

auto

rizad

as

libro para aprender a desarrollar software usando los principios de laorientación a objetos correctamente. Aunque utiliza algunos de lospatrones de diseño GoF, en vez de describirlos en forma aislada (comola mayoría de los catálogos) lo hace integrándolos al proceso dedesarrollo. Adicionalmente el texto presenta con buen tino nuevosenfoques como Agile Development y en particular Extreme Programming;en este contexto se describe muy claramente como utilizar testing desdeel comienzo de un proyecto de desarrollo. Los autores vuelcan en el librosu experiencia en enseñanza del diseño con objetos lo cual hace que eltexto sea muy didáctico y particularmente fácil de leer. El libro contieneademás una buena cantidad de código ejemplo, diagramas UMLintroducidos correcta y claramente, y también un par de patrones noincluidos en el libro de Gamma et al. Muy recomendable como guíaintroductoria, no solamente al concepto de patrón de diseño, sinofundamentalmente al diseño software usando objetos correctamente.

Sección técnica: "Tecnologías y Empresa"(Didac López Butifull, Francisco Javier Cantais Sánchez)

Tema: Tema: Tema: Tema: Tema: el Libro.

Harvard Business Essentials.Harvard Business Essentials.Harvard Business Essentials.Harvard Business Essentials.Harvard Business Essentials. Estrategia. Gestión 2000, ISBN:8423424316. La necesidad de alinear negocio y tecnología suponen queel CIO debe hablar un lenguaje próximo al de la gestión empresarial yha de pensar con visión estratégica. Es por ello que recomendamos estelibro, muy fácil de leer y completo, abierto a todos los directivos decualquier área funcional, que facilita herramientas y conocimientospara que los directivos puedan colaborar entre ellos y crear e implementarestrategias basadas en objetivos de negocio.

Tema:Tema:Tema:Tema:Tema: la Herramienta: i-doIT.

En esta URL <http://www.i-doit.org/english/index.php> podréisencontrar esta herramienta de CMDB basada en ITIL y de libreacceso, muy completa que se puede enlazar con herramientas dehelp desk y de IT Governance. Es muy completa y fácil de gestionar,además de disponer de un buen nivel de documentación.

Tema: Tema: Tema: Tema: Tema: la Web: ITSMF España <http://www.itsmf.es/>.

En esta URL encontrareis todo lo referente al capítulo español delIT Services Management Forum (ITSMF), que recientemente hacelebrado su primer congreso anual después de su primer año deexistencia, coincidiendo con la creación del capítulo de Catalunya.

Tema: Tema: Tema: Tema: Tema: el Artículo: "Las 15 grandes carencias de ITIL".

<http://gobiernotic.blogspot.com/2006/12/las-15-grandes-caren-cias-de-itil.html>. En este articulo su autor, Antonio Valle, en sublog nos cuenta cuales son a su modo de entender las 15 principalescarencias de ITIL V2. A modo de resumen son:1. Un modelo de madurez.2. Un buen paquete de métricas.3. La gestión de los requerimientos.4. Operaciones.5. Seguridad.6. Ciclo de Vida del Servicio.7. Gestión de Proveedores.8. Desarrollo.9. Paso a. producción.10.Gestión de Proyectos.11.Gestión de Personal.12.Estrategia.13.Gestión de Riesgos.14.Finalización del Servicio.15.Guías y Ejemplos de Implantación.

En el artículo referenciado se puede ampliar esta información.

Tema: Tema: Tema: Tema: Tema: el Documento: "Certificación CAYSER".

La asociación de española para la dirección de la informática,"AEDI" <http://www.aedi.es>, ha creado y promociona un sello decertificación de calidad, una marca de garantía, que distingue a lesempresas proveedoras comprometidas con la oferta en condicionesde calidad de servicios y productos informàticos. En esta URL sepuede acceder a toda la documentación que especifica este sello decalidad. <http://www.aedi.es/cayser/cayser.asp# Documentacion>.

Sección técnica: "TIC y Turismo"(Andrés Aguayo Maldonado, Antonio Guevara Plaza)

Tema:Tema:Tema:Tema:Tema: CINNTA.

La Consejería de Turismo, Comercio y Deporte de la Junta deAndalucía ha puesto en marcha el Centro de Innovación Turística deAndalucía (CINNTA). El proyecto se constituye como fundación yaglutina a 27 entidades del sector turístico, universidades, agenteseconómicos y sociales y centros tecnológicos. Este centro, con sedeen Marbella (Málaga), es el segundo que se crea en España dedicadoa la investigación e innovación del sector tras el de Baleares. ElCINNTA tiene como objetivo general convertirse en un instrumentopara integrar y aglutinar los esfuerzos de entidades públicas yprivadas en la materia y para potenciar la competitividad del destinoAndalucía mediante el impulso de los procesos de I+D+i.

A través de la fundación, se realizarán investigaciones de mercadopara el diseño futuro de estrategias, se compartirá información y sepondrán en práctica ideas innovadoras para la creación de nuevosproductos acordes con las necesidades reales del sector. Así, estáprevisto poner en marcha diferentes líneas de actuación, como larealización de estudios sobre competidores, productos, proveedoresy clientes, la creación de una unidad de vigilancia tecnológica y eldesarrollo de actividades de formación y profesionalización deempresas. Igualmente, el CINNTA diseñará nuevos modelos degestión y producción más eficientes para empresas, innovará en lacreación de productos y metodologías de planificación, realizaráproyectos de I+D (ingeniería, instalaciones y servicios turísticos) ycreará documentos técnicos para desarrollar normativas sobre cali-dad, medioambiente y promoción de la cultura de la innovación.

Entre los integrantes de la Fundación del CINNTA se encuentranvarias universidades andaluzas, los diferentes patronatos provincia-les de Turismo, representantes sindicales y patronales, asociacionesturísticas, el Instituto Andaluz de Tecnología o la entidad de certi-ficación en sistemas de calidad AENOR. Entre los colaboradores,destacan Google, Yahoo o MSN.

Como punto de partida y coincidiendo con su inauguración en octubre,se celebraron las I Jornadas de Turismo e Innovación, con una serie deponencias articuladas en varias secciones: Innovación y Turismo,Marketing on-line y Turismo, Nuevos retos y Experiencias prácticas. Sepuede obtener más información y descargar las actas de las jornadas enla dirección url: <http://www.jornadas turismoinnovacion.es>.

novática nº 184 noviembre-diciembre 200670

sociedad de la información Futuros emprendedores

sociedad de la información

1. IntroducciónLas investigaciones suman miles y el númerode personas estudiadas, millones. Ya no haydudas, la famosa máxima del poeta Juvenalestá científicamente comprobada: "Menssana in corpore sano". Así era para los roma-nos de principios del siglo II y lo es para losespañoles del siglo XXI. La actividad físicaes uno de los más eficaces soportes no solode la salud sino también del equilibrio emo-cional.

El estrés es algo habitual en nuestras vidas,no puede evitarse, ya que cualquier cambioal que debamos adaptarnos representa estrés.Es la reacción de nuestro organismo frente ala presión constante, y, cuando los mecanis-mos de recuperación fallan, se producen lasenfermedades de adaptación. Nuestro cuer-po responde con cansancio, problemas di-gestivos, dolores de cabeza, pérdida del ape-tito, se nos olvidan las cosas, cambia nuestroestado de ánimo, tenemos problemas paradormir o descansar, dolores musculares, irri-tabilidad o aislamiento, aumentan las fre-cuencias respiratorias y cardíacas, entre otrossíntomas.

Una de las soluciones propuestas por losmédicos para este nuevo mal es realizarejercicios físicos, ya sea en un gimnasio o enclases de bailes. Pero el problema que tienela sociedad actual es el tiempo. El aceleradoritmo de vida y los horarios laborables hacenque sea totalmente imposible tener un huecoen nuestra vida para este fin.

El otro gran problema social es el sobrepesoy sus correspondientes enfermedadesvasculares. La mala alimentación está dan-do lugar a que un alto porcentaje de indivi-duos del Primer Mundo tengan problemasde sobrepeso. De nuevo la solución pasa porla realización de ejercicio físico junto a die-tas concretas.

Aún otro de los problemas que nos encon-tramos junto al tiempo es el de la vergüenza.El rechazo social a las personas consobrepeso crea un aislamiento de estas per-sonas que les lleva a ser incapaces de ir a ungimnasio por el qué dirán. Si a estos factoresañadimos el económico, nos encontramosante una barrera infranqueable para muchaspersonas.

2. Step by Step: aspectos tecnoló-gicosAnte este escenario nos surgió la idea depoder realizar ejercicio en casa con unamonitorización personalizada y adecuada alos tiempos que corren. Hoy en día la tecno-logía está en todos los rincones de nuestravida diaria, la televisión, la telefonía móvil,Internet, los nuevos electrodomésticos, etc.Todas estas implantaciones son el resultadode mezclar varias técnicas y tecnologías quepor separado no aportan mucho, y que jun-tas suponen la aparición de nuevos produc-tos que nos facilitan la vida.

De esta forma surgió Step by Step. . . . . No essólo una aplicación para usuarios, es muchomás. Es un sistema completo que permite lacompra/venta de paquetes de ejercicios através de Internet. Para ello es necesariofacilitar el camino a las empresas que quie-ran entrar en este mercado. Veamos cualesson los componentes tanto hardware como

software que nos permitirán exponer los ejer-cicios a través de Internet.

2.1. EquipamientoEl equipamiento necesario para poder reali-zar la captura de movimientos en el empla-zamiento del usuario consiste en: Dos webcams, para realizar la captura del

movimiento en 2D, colocadas a 90 gradoscon respecto al usuario, y a una distanciapredefinida para poder capturar su cuerpo alcompleto. Para facilitar la detección del movimiento

se recomienda colocar en cinco puntos delcuerpo (cabeza, muñecas y tobillos) tiras dematerial reflectante. Una iluminación adecuada de la habita-

ción para que se pueda seguir el movimientodel cuerpo. Suelen bastar dos simples lám-paras (por ejemplo, dos flexos de estudio)colocados tras las cámaras.

Como vemos, el equipamiento necesario es

Step by Step:Mens sana in corpore sano

Miguel Ángel Ramos Barroso,Javier Cantón Ferrero, JavierFernández Rodríguez, JuanMaría Laó RamosEscuela Técnica Superior de Ingeniería In-formática, Universidad de Sevilla

<{marb2000, mudi2k, javiuniversidad, juanlao}@<{marb2000, mudi2k, javiuniversidad, juanlao}@<{marb2000, mudi2k, javiuniversidad, juanlao}@<{marb2000, mudi2k, javiuniversidad, juanlao}@<{marb2000, mudi2k, javiuniversidad, juanlao}@gmail.com>gmail.com>gmail.com>gmail.com>gmail.com>

Resumen: a día de hoy la informática se ha introducido en nuestras vidas de manera similar a cómo lohizo el teléfono o la televisión. De la misma manera que esperamos que al descolgar el teléfono éstenos permita realizar una llamada, también esperamos que al encender el ordenador éste nos ofrezcatodos los servicios posibles. Step by Step es un entrenador personal para realizar ejercicio de cualquiertipo desde casa, con tan sólo dos webcams y una conexión a Internet. La propuesta es facilitar larealización de ejercicio físico controlado, ya sea en forma de bailes, ejercicios de rehabilitación, man-tenimiento o relajación.

Palabras clave: ejercicios físicos a través de Internet, estudiantes emprendedores, innovación tecno-lógica, ingeniería de desarrollo en Internet, pasión tecnológica, producto informático novedoso, Reali-dad Aumentada.

Autores

Miguel Ángel Ramos Barroso estudió 5º de Ingeniería Informática en la Universidad de Sevilla duranteel curso 2005-2006.

Javier Cantón Ferrero estudió tercer curso de Ingeniería Informática en la Universidad de Sevilla duranteel curso 2005-2006.

Javier Fernández Rodríguez estudió tercer curso de Ingeniería Técnica en Informática de Sistemas enla Universidad de Sevilla durante el curso 2005-2006.

Juan María Laó Ramos estudió tercer curso de Ingeniería Técnica en Informática de Sistemas en laUniversidad de Sevilla durante el curso 2005-2006.

Los cuatro autores son actualmente becarios para la Universidad de Sevilla realizando un trabajode I+D+I para la Estación Biológica de Doñana. El pasado mes de abril formando equipo resulta-ron ganadores del certamen nacional Imagine Cup organizado por Microsoft para premiar los me-jores proyectos de estudiantes en cuanto a innovación y creatividad. Su proyecto ganador fue“Step by Step”. Posteriormente, profundizando en este mismo proyecto, en agosto representaron anuestro país en la final mundial del mismo certamen celebrada en Nueva Delhi (India) y sobre cuyaexperiencia nos escriben en este artículo.

novática nº 184 noviembre-diciembre 2006 71

Futuros emprendedores sociedad de la información

sociedad de la información

muy simple. Una pequeña representacióndel sistema lo tenemos en la figura 1figura 1figura 1figura 1figura 1.

3.2. Software desarrolladoLa base de este sistema consiste en obtenerla información del ejercicio que está reali-zando el usuario a partir de las dos cámaras,obteniendo pares de puntos en dos dimen-siones. Esta información es la que se guardaen las estructuras de datos que se han desa-rrollado y a partir de ella se hace una trasla-ción a un mundo en tres dimensiones.

El software desarrollado consta de:a)a)a)a)a) Calibration System, Calibration System, Calibration System, Calibration System, Calibration System, o sistema de cali-brado. Mediante el uso de la tecnología deRealidad Aumentada[1] y a partir del reco-nocimiento de un patrón, estableceremospuntos de referencia en el mundo real nece-sarios para construir un mundo virtual. Estaaplicación y el asistente que integra, nospermite colocar las webcams en las posicio-nes correctas para conseguir el fin anterior.Esto se consigue a partir del patrón queestará impreso en una hoja A4 y se colocaráen el lugar donde el usuario realizará losejercicios. El sistema, una vez que cada cá-mara reconozca ese patrón, tendrá un puntode referencia y distinguirá a qué altura y aqué distancia se encuentra y cuál es el cabe-ceo de cada cámara, e indicará al usuario deforma gráfica y fácil cual es la posicióncorrecta de cada cámara.[5].

De esta manera obtendremos los ángulos dereferencia necesarios para poder realizar lacaptura del movimiento. A través de las co-ordenadas obtenidas por las webcams en2D, hay que saber cuales son los ángulos enlos que se encuentra el usuario, para poderrealizar la traslación a un mundo en 3D yrepresentarlo [8]. La figura 2 figura 2 figura 2 figura 2 figura 2 representa el

esquema de la reconstrucción del mundo en3D a partir de la visión de cada cámara.

b)b)b)b)b) Central Production.Central Production.Central Production.Central Production.Central Production. Esta aplicación estádirigida a las empresas que deseen entrar eneste sector, el de la venta de ejercicios através de Internet. Es la encargada de pro-porcionar asistencia en la producción y ges-tión de todos los ejercicios y paquetes deejercicios publicados en Internet. Está for-mada por un conjunto de herramientas talescomo:

Capture system: Es el sistema que se en-carga de capturar y de seguir el movimientodel cuerpo humano en tiempo real.

Central Production: Es un visor que repre-senta en un pequeño entorno 3D el ejerciciorealizado.

Package Center: Es la herramienta encar-gada de gestionar los ejercicios por medio depaquetes de ejercicios que se pondrán a laventa.

News: Un sistema de noticias con las queinformar a los usuarios de actualizaciones,novedades, etc.

User Management: El sistema de gestiónde usuarios, que permite gestionar toda lainformación relacionada con los usuarios

Con esta aplicación se pretende que sean laspropias empresas las innovadoras en el sec-tor, y que graben y ofrezcan los ejerciciosmás convenientes para posicionarse en estenuevo mercado.

La figura 3figura 3figura 3figura 3figura 3 nos ilustra la presentación queofrece Central Production al usuario final.

c)c)c)c)c) Step by Step. Step by Step. Step by Step. Step by Step. Step by Step. Es la aplicación de descar-ga disponible para todos los usuarios, con laque poder comprar y realizar los ejerciciosque haya ofertados. Integra también el mó-dulo Capture System necesario para el se-guimiento de los movimientos del usuario.De esta forma se puede imbuir al usuario enun entorno en 3D como vemos en la figura 4figura 4figura 4figura 4figura 4.

Destacamos que las esferas más claras (blan-cas) que se observan son los puntos delejercicio que se va a realizar y marcan losmovimientos que debe hacer el usuario. Esteúltimo es representado por otro conjunto deesferas de color (más oscuras en la figura),que se tornarán verdes si están en la posicióncorrecta y rojas en caso contrario. Todo estose consigue a través de un sistema de tracking[2] [3] basado en el motor Sharper CV [6].A lo largo de la ejecución del ejercicio seelabora una estadística con el grado de co-rrección obtenido, permitiendo obtener unaevaluación del mismo durante su realiza-

Figura 1. Equipamiento necesario para el usuario de Step by Step.

Figura 2. Esquema de la reconstrucción del mundo en 3D a partir de las imágenes obteni-das por las webcams.

novática nº 184 noviembre-diciembre 200672

secciones técnicas Informática Gráfica

secciones técnicas

ción, así como una descripción de las mejo-ras obtenidas al realizarlo varias veces [4].

Central Production y Step by Step se basanen los mismos principios para tratar lasimágenes que se obtienen de las webcams.Realizar la captura en dos dimensiones ytransformar los puntos detectados en pun-tos 3D, con el fin de fijar un espacio virtualen el que realizar, comprobar y evaluar elejercicio.

Con la aplicación para empresas CentralProduction se ofrece un sistema para la gra-bación, gestión y publicación de ejercicios através de Internet. La idea de esta aplicaciónes que sea un profesional el que realice elejercicio delante de las webcams dependien-do del producto que se quiera ofrecer. Sedeja en manos de estos profesionales elegircuál es el ejercicio más adecuado.

La sencillez de manejo para las empresasque quieran entrar en este mercado es unfactor clave. Nuestra idea en torno a estefactor es dejar que las empresas se dediquena lo que saben hacer, esto es, producir elmaterial. Nosotros sólo le facilitamos la for-ma de exponer esos ejercicios en Internet,dejando en sus manos la innovación a lahora de presentar los productos a sus clien-tes en forma de paquetes de ejercicios, nue-vos bailes o ejercicios de relajación y derehabilitación.

3.3 Tecnologías utilizadas

Windows Communication Foundation[9].Es un framework desarrollado por Microsoft

que facilita la creación de sistemas de comu-nicación para aplicaciones distribuidas. Conél conseguimos poder establecer las comuni-caciones necesarias entre la base de datos ylas aplicaciones cliente y servidor de muydiversas maneras, pudiendo configurar au-tomática o manualmente cómo se van acomunicar estas aplicaciones. sin verse afec-tada para nada la funcionalidad del sistema.

En la figura 5figura 5figura 5figura 5figura 5 ilustramos nuestro esquemade funcionamiento basado en servicios webconsumidos por las aplicaciones Step byStep y Central Production. De este modo,

aislamos la lógica de negocio facilitando asíla escalabilidad y el mantenimiento del siste-ma.

Realidad Aumentada.Esta tecnología permite imbuir objetosvirtuales en el mundo real. Actualmente, lamayoría de las investigaciones sobre ellaestán dirigidas a incluir gráficos y elementosen imágenes procesadas en tiempo real. Losmayores avances que se están dando ahoraincluyen el seguimiento del movimiento.

Un ejemplo de uso muy claro de esta tecno-logía lo podemos ver cuando se televisa unpartido de fútbol y vemos cierta publicidad oel resultado del partido al comienzo de cadaparte del partido.

Hemos usado esta tecnología para podercalibrar el sistema a partir de un patrónimpreso en una página A4. Este patrón esreconocido por el sistema obteniendo unpunto de referencia en el mundo real. Y apartir de ese punto, podemos reconstruirtodo un mundo virtual en la que introducir alusuario para realizar los ejercicios que de-see.

DirectX.DirectX [7] es un conjunto de librerías quenos permiten acceder al sistema gráfico de lamáquina proveyendo de una capa comúnque unifica el hardware que podemos encon-trar en distintas máquinas, asegurando deesta forma que nuestro sistema puede serejecutado en cualquier máquina actual en elmercado.

Al ser todas estas tecnologías punteras en elcampo de la programación y dada la arqui-tectura en n-capas de todo el sistema es

Figura 3. Aspecto de la aplicación Central Production para empresas.

Figura 4. Step by Step: las esferas más claras nos indican los movi-mientos a realizar y las más oscuras representan al usuario haciendoel ejercicio.

novática nº 184 noviembre-diciembre 2006 73

Informática Gráfica secciones técnicas

secciones técnicas

Figura 5. Arquitectura del sistema basada en la tecnología de Servicios Web.

posible actualizar cualquier módulo de ma-nera transparente. Es decir, podemos apro-vechar las últimas novedades referentes aestas tecnologías para aumentar lafuncionalidad de nuestro sistema. Como porejemplo el adaptar la interfaz de usuariopara Windows XNA, permitiendo de estamanera poder ejecutar esta aplicación tantoen PC’s de sobremesa o portátiles como enla nueva XBOX 360.

4. Utilización del sistemaUno de los objetivos de este proyecto es lafacilidad de uso tanto por parte de los usua-rios que lo consuman como por las empresasque quieran entrar en este mercado. Despuésde haber hecho un estudio sobre las interfacesde usuario que más éxito ha tenido en elmundo del software optamos por un modelomuy sencillo, visual e intuitivo.

En la aplicación cliente, el usuario sólo debeidentificarse en el sistema con sus credencia-les: nombre de usuario y contraseña. Unavez validadas estas credenciales tendrá acce-so a todas las opciones disponibles para elusuario:

Lista de paquetes disponibles para ad-quirir con una completa descripción del con-junto de ejercicios , incluyendo precio, etc.

Lista de paquetes adquiridos con la mis-ma descripción detallada de la lista de ejer-cicios disponibles.

Lista de evaluación sobre los ejerciciosadquiridos. A medida que se realiza un ejer-cicio de alguno de los paquetes, se obtieneuna puntuación asociada a la fecha y hora derealización. Se crea un pequeño historial enel que puede observarse el grado de progresoen la realización de un ejercicio completo.

Subsistema para la calibración del siste-ma. Las webcams deben colocarse en unadeterminada posición para poder realizar lacaptura del movimiento del usuario de for-ma adecuada. Para ello se suministra unaaplicación que permite realizar esta calibra-ción de una forma muy sencilla a través de unasistente o wizard que irá indicando al usua-

rio cómo colocar las cámaras.Módulo de realización del ejercicio. Una

vez que el sistema está calibrado ya es posi-ble comenzar la realización del ejercicio. Elproceso que se sigue es indicar al usuariouna postura inicial para que el sistema ob-tenga un patrón del usuario, esto es, concre-tar en qué posición están los diferentes pun-tos del cuerpo del usuario, para poder reali-zar el seguimiento del movimiento y com-probar si se está realizando correctamen-te[6].

Reconocimiento de voz [10]. Se hacenecesario poder controlar parte de la aplica-ción del cliente por la voz. Durante la reali-zación del ejercicio se pueden decir ciertoscomandos para parar, comenzar y reanudarel ejercicio.

5. Nuestra experiencia en la finalde la Imagine CupNo sabíamos con qué nos íbamos a encon-trar. Cómo serían el resto de competidores,ni siquiera sabíamos si el inglés que estuvi-mos practicando iba a estar a la altura. Loque teníamos claro es que íbamos a disfrutarconociendo a gente de todo el mundo, apa-sionados por la tecnología como nosotros.

El ambiente que se respiraba desde el primerhasta el último día era una atmósfera deafabilidad, cordialidad y, como ya hemosdicho, pasión por las nuevas tecnologías, y elnivel de competitividad era nula.

El primer día por la tarde fue la primeraronda de exposiciones. Había cuarenta y unproyectos en concurso y nos dividieron encuatro grupos, cada grupo con un juradodiferente. El segundo día tocaba una jorna-da de exposición de todos los proyectos enun stand que tenía cada grupo asignado parapermitir a los jurados y a la prensa hacerpreguntas e informarse sobre todos ellos.

Una pequeña anécdota es que durante unmes estuvimos preparando nuestro ingléspara poder estar a la altura de tal evento, y en

esta jornada cada miembro de nuestro equi-po expuso el proyecto unas cinco veces eninglés. Luego, cuando se acercaron a intere-sarse por nuestro proyecto los que represen-taban a Mexico, Guatemala, Colombia etc,teníamos que pararnos a pensar cómo expo-nerlo ya que sólo lo habíamos preparadopara hacerlo en inglés. Es decir, nos "costa-ba" más exponerlo en castellano que en in-glés.

Nunca habíamos sabido qué se siente en unafinal mundial, y la verdad nos ha dejadohuella. No había ningún tipo decompetitividad entre los diferentes equipos ycuando en la mañana de exposición nosacercábamos a preguntar y a saber de quéiban los diferentes proyectos nadie se dejabanada en el tintero. Lo que más nos gusto ynos contagió fue la ilusión y las ganas conque lo exponían.

Al fin y al cabo esto es lo único que senecesita para poder hacer lo que cada uno seproponga, ilusión.

Referencias

[1] N. Sánchez Martín, B. Arias Pérez, D.González Aguilera, J. Gómez Lahoz. "Análisisaplicado de métodos de calibración de cámaraspara usos fotograméticos". VIII Congreso Nacionalde Topografía y Cartografía. Octubre 2004.[2] Chung Wing Ng, Irwin King, Michael R. Lyu.Video Comparison Using Tree Matching Algorithms.Department of Computer Science and Engineering,The Chinese University of Hong Kong. <http://www.cse .cuhk . edu .hk /~ lyu /pape r_pd f /videocompfin.pdf>.[3] Alexandru O. Balan, Leonid Sigal, MichaelJ. Black. A Quantitative Evaluation of Video-based3D Person Tracking. Department of ComputerScience, Brown University, Providence, USA, 2005.[4] Aude Billard, Maja Matarié. Learning humanarm movements by imitation:Evaluation of abiologically-inspired connectionist architecture.MIT, Cambridge, Septiembre 2000.[5] Chung-Wing Ng. Advanced Digital VideoInformation Segmentation Engine. Tesis supervi-sada por Michael R. Luy y Irwin King. Universidadde Hong Kong. 2002.[6] SharperCV Project. <http://www.cs.ru.ac.za/research/groups/SharperCV>.[7] Microsoft DirectX SDK. <http://msdn.microsoft.com/directx/sdk>.[8] Jean-Yves Bouguet. Camera calibrationtoolbox for Matlab. <http://www.vision.caltech.edu/bouguetj/calib_doc>.[9] Windows Communication Foundation.<http://wcf.netfx3.com>[10] Microsoft Speech – Speech API SDK. <http:// w w w . m i c r o s o f t . c o m / s p e e c h / t e c h i n f o /apioverview>.

novática nº 184 noviembre-diciembre 200674

sociedad de la información Novática interactiva

sociedad de la información

Cuando en mayo de 2006 tuvimos noticiade que el Formato de Documento Abiertohabía sido aprobado por la ISO no duda-mos ya más y programamos una monogra-fía con tal motivo.

En efecto, desde que ODF nació prometía,y todavía promete, ser un factor decisivoen la interoperabilidad futura de nuestrasaplicaciones de escritorio (procesadoresde texto, hojas de cálculo, etc.).

Es más, nuestra idea sobre la relevancia deODF se vió refrendada cuando en julioMicrosoft, que había sido reacia a partici-par en la definición de ese standard, anun-ció Open XML Translator, un traductor decódigo abierto de los formatos de sus pro-ductos a ODF. Parecía que el consensoalrededor de ODF se estaba extendiendo...

Sin embargo, en el momento de editar estamonografía, nos encontramos con un pa-norama incierto y complejo en cuanto aanálisis.

Todos pensábamos que un estándar enInformática estaba destinado a "sentarunas bases" sobre las que competir a nivelde productos y de implementaciones. Encambio, ahora se nos está hablando de"competencia entre estándares", es decirde competencia a la hora de estableceresas mismas bases.

Por otra parte, las opiniones recogidas enesta monografía difieren en su misma esen-cia. Así, mientras algunas voces como lade John VenatorJohn VenatorJohn VenatorJohn VenatorJohn Venator, según recoge el artículode John GJohn GJohn GJohn GJohn Gøøøøøtzetzetzetzetze, consideran positiva esacompetencia entre estándares, otros artí-culos como el de Alberto BarrionuevoAlberto BarrionuevoAlberto BarrionuevoAlberto BarrionuevoAlberto Barrionuevo y elde Sam HiserSam HiserSam HiserSam HiserSam Hiser y Gary EdwardsGary EdwardsGary EdwardsGary EdwardsGary Edwards nos expo-nen de manera razonada todo lo contrario.

Claro está que si hablamos de aspectosesenciales, al leer el artículo de DavidDavidDavidDavidDavidWheelerWheelerWheelerWheelerWheeler podemos sacar como principalconclusión que "abierto" significa básica-mente "llevado a consenso", es decir unconcepto antagónico precisamente al defavorecer una competencia por separado.

Por otra parte, en el terreno de las actitu-des que esta "competencia" provoca entrelos compradores, en particular entre losresponsables informáticos de las empre-sas, Sam HiserSam HiserSam HiserSam HiserSam Hiser y Gary Edwards, Gary Edwards, Gary Edwards, Gary Edwards, Gary Edwards, nosexplican que, ante el turbio panorama, lapropensión de éstos a no tomar decisiones"arriesgadas" puede guiar sus decisionesde compra a partir de ahora. Mal asuntoparece el que el miedo al fracaso tenga queacabar siendo un factor de peso en laelección de los productos ofimáticos.

Y aún en el terreno técnico las opinionesdifieren y así mientras el informe de IDCNordic citado por John GJohn GJohn GJohn GJohn Gøøøøøtzetzetzetzetze no ve pro-

Competencia entre estándares,¿va a ser posible su coexistencia?

blemas en la coexistencia de dos están-dares, Hiser Hiser Hiser Hiser Hiser y Edwards Edwards Edwards Edwards Edwards nos inquietan conestimaciones de que, por razones intrínse-cas, las conversiones entre ambos formatosno podrán pasar de entre un 60 y un 85% defiabilidad. ¿Dónde quedará entonces nues-tro objetivo de interoperabilidad?

Por último, Marco FiorettiMarco FiorettiMarco FiorettiMarco FiorettiMarco Fioretti nos aporta aúnnuevas dudas e inquietudes al hacernosver cómo la extensibilidad apenas limitadade ODF, una característica que podríamosconsiderar como positiva, podría acarrearen el futuro consecuencias negativas paralos usuarios si no se toman ahora las pre-venciones adecuadas.

¿Serán nuestros productos de softwareofimático interoperables en el futuro? ¿Se-guirán nuestros hijos teniendo los proble-mas de compartición de ficheros y datosque nosotros hemos venido experimentan-do en el pasado? ¿Qué podemos hacer alrespecto?

Si tienes algo que decir o reflexionar sobreeste apasionante tema, no te pierdas nues-tro debate a partir del dia 5 de marzo a partir del dia 5 de marzo a partir del dia 5 de marzo a partir del dia 5 de marzo a partir del dia 5 de marzo en losforos interactivos de ATI.....

Foro de Debate

<http://www.ati.es/foros/><http://www.ati.es/foros/><http://www.ati.es/foros/><http://www.ati.es/foros/><http://www.ati.es/foros/>

ESTANDARES ABIERTOSDE DOCUMENTOS

Participa en nuestro debate a partir del dia 5 de marzo

Promovido por EstandaresAbiertos.org y ATI y moderadopor Alberto Barrionuevo y Miguel Angel Amutio, autores en esta monografía.

http://www.ati.es/foros

Será necesario estar registrado en los foros de ATI y ademássolicitar incorporarse al Grupo de Usuarios "Estándares abiertos de documentos". www.ati.es

novática nº 184 noviembre-diciembre 2006 75

programar es crear sociedad de la información

sociedad de la información

¿Cuántos puntos de una malla hay en un polígono? Antes de resolveresta cuestión vamos a explicar algunos conceptos. Consideramos lamalla de puntos del plano de coordenadas enteras. Éste es unmodelo discreto del plano bastante habitual. Un polígono estádeterminado por la lista de sus vértices en el orden en que aparecenal recorrer su frontera. Aunque todos los vértices de un polígonosean puntos de la malla, puede ocurrir que no haya más puntos dela malla en su frontera. En el ejemplo de la figura el polígono tiene12 vértices y tiene 7 además en su frontera.

El problema consiste en escribir un programa para calcular cuántospuntos de la malla hay sobre la frontera de un polígono cuyosvértices están en la malla.

Descripción de las entradas

Un conjunto de ejemplos, cada uno consta de 2n+1 enteros, uno encada línea. El primero indica el número de vértices del polígono, y lossiguientes, de dos en dos, corresponden a las coordenadas de losvértices. Un cero señala el final de las entradas.

Descripción de las salidas

Para cada polígono, un entero indicando el número total de puntosde la malla sobre el la frontera del polígono.

Polígonos en mallaDolores Lodares GonzálezFacultad de Informática, Universidad Politécnica de Madrid

<dlodares@fi.upm.es><dlodares@fi.upm.es><dlodares@fi.upm.es><dlodares@fi.upm.es><dlodares@fi.upm.es>Este es el enunciado del problema A de los planteados en el IV ConcursoUniversitario de la Comunidad Autónoma de Madrid (CUPCAM 2006) delque ATI fue entidad colaboradora.

1231112426-16-3102-3-1-2-3-1-10-32-10

19

Salida para el ejemplo de entrada

Ejemplo de entrada

novática nº 184 noviembre-diciembre 200676

asun

tos

inte

riore

s

asuntos interiores

coordinación editorial programación de Novática

Continúa desarrollándose el plan de digitalización completaContinúa desarrollándose el plan de digitalización completaContinúa desarrollándose el plan de digitalización completaContinúa desarrollándose el plan de digitalización completaContinúa desarrollándose el plan de digitalización completade de de de de NováticaNováticaNováticaNováticaNovática

Las contribuciones de numerosos socios están permitiendo avanzaren la digitalización completa de NováticaNováticaNováticaNováticaNovática, un plan cuyo desarrolloestá siendo gestionado por el anterior director de nuestra revista,Rafael Fernández CalvoRafael Fernández CalvoRafael Fernández CalvoRafael Fernández CalvoRafael Fernández Calvo, en colaboración con el responsable admi-nistrativo de ATI Valencia, Jorge LlácerJorge LlácerJorge LlácerJorge LlácerJorge Llácer, contando con la coleccióncompleta de NováticaNováticaNováticaNováticaNovática donada por el socio Mauricio CórdobaMauricio CórdobaMauricio CórdobaMauricio CórdobaMauricio Córdoba.

En estos momentos se puede acceder en la Intranet a todos losnúmeros a partir del 74 (mayo-junio de 1988) más algunos anterio-res cuyas monografías constituyeron hitos importantes en la historiade nuestra revista e incluso del sector TIC en nuestro país, así comoa los números 0 (noviembre-diciembre de 1974) y 1 (enero-febrerode 1975).

Destacamos también los números 34 y 71, en los cuales se publicóuna interesante historia de ATI escrita por Pedro Gómez GrauPedro Gómez GrauPedro Gómez GrauPedro Gómez GrauPedro Gómez Grau, quefue presidente de nuestra asociación en los primeros años noventa,mientras que la historia del nacimiento de Novática, escrita porJulián MarceloJulián MarceloJulián MarceloJulián MarceloJulián Marcelo, primer director de NováticaNováticaNováticaNováticaNovática, la encontramos en elnúmero 145. Todo ello está en <https://intranet.ati.es/novatica/>.

Pero para completar este plan de digitalización se necesitan másaportaciones y a tal fin recordamos que éstas, con un mínimo de 20euros, que es lo que cuesta digitalizar cada número, deben hacersemediante transferencia a la siguiente cuenta corriente de ATI Valen-cia en BANCAJA: 2077 0075 13 1101128334.

Se ruega que en la transferencia se incluya el siguiente texto:"Novática digital". Es importante señalar que las transferencias porInternet de pequeñas cantidades (hasta unos 100 euros) tienen en lamayoría de los bancos y cajas una comisión mucho más reducidaque las tradicionales (1 euro aproximadamente en el primer caso,frente a unos 3,50 euros en el segundo).

La lista de los socios que hayan contribuido a este proyecto figuraráen la Intranet, para dejar constancia de su generosidad.

Muchas gracias a todos,

Llorenç Pagés CasasLlorenç Pagés CasasLlorenç Pagés CasasLlorenç Pagés CasasLlorenç Pagés CasasCoordinación Editorial de Novática

Fe de erratas (números 180 y 181)Fe de erratas (números 180 y 181)Fe de erratas (números 180 y 181)Fe de erratas (números 180 y 181)Fe de erratas (números 180 y 181)

En el nº 180, página 60, en el artículo titulado "Modelos en UML:un enfoque semiótico", ", ", ", ", la Tabla 2Tabla 2Tabla 2Tabla 2Tabla 2 muestra erróneamente lomismo que la Figura 3Figura 3Figura 3Figura 3Figura 3 de la página anterior. Para subsanar estedefecto, hemos generado un nuevo fichero pdf en el que hemosincluido correctamente el contenido original de dicha tabla. Pararecuperar el artículo correctamente pueden dirigirse a la web deNovática correspondiente a dicho número <http://www.ati.es/novatica/2006/180/nv180sum.html>, o bien solicitar el nuevoarchivo PDF via correo electrónico a <novatica@ati.es>.

En el nº 181, en el artículo titulado "Evaluación comparativa deherramientas CASE para UML desde el punto de vista notacional",sumario y página 59, el segundo apellido de la tercera autora estáequivocado, debería ser "Blázquez".

Desde aquí, nuestras más sinceras disculpas tanto a los autoresafectados como a todos nuestros lectores.

Próximas monografíasPróximas monografíasPróximas monografíasPróximas monografíasPróximas monografías

Por acuerdo de los Consejos Editoriales de Novática Novática Novática Novática Novática y UPUPUPUPUPGRADE,los temas y editores invitados de las monografías que publicaremosdurante 2007 son éstos:

Nº 185 (enero-febrero): "Buscadores web". Editores invitados: Ri-Ri-Ri-Ri-Ri-cardo Baeza-Yatescardo Baeza-Yatescardo Baeza-Yatescardo Baeza-Yatescardo Baeza-Yates (Yahoo! Research, Universitat Pompeu Fabra),José María Gómez HidalgoJosé María Gómez HidalgoJosé María Gómez HidalgoJosé María Gómez HidalgoJosé María Gómez Hidalgo (Universidad Europea de Madrid) yPaolo BoldiPaolo BoldiPaolo BoldiPaolo BoldiPaolo Boldi (Università degli Studi di Milano).

Nº 186 (marzo-abril): "Informática para deficientes visuales". Edi-tores invitados: Josep LladósJosep LladósJosep LladósJosep LladósJosep Lladós (Centre de Visió per Computador,Universitat Autònoma de Barcelona) Jaime López KraheJaime López KraheJaime López KraheJaime López KraheJaime López Krahe (Universitéde Paris VIII) y Dominique ArchambaultDominique ArchambaultDominique ArchambaultDominique ArchambaultDominique Archambault (Université de Jussieu).

Nº 187 (mayo-junio): "Certificaciones profesionales en Informáti-ca". Editores invitados: Luis Fernández SanzLuis Fernández SanzLuis Fernández SanzLuis Fernández SanzLuis Fernández Sanz y María José GarcíaMaría José GarcíaMaría José GarcíaMaría José GarcíaMaría José GarcíaGarcíaGarcíaGarcíaGarcíaGarcía (Universidad Europea de Madrid).

Nº 188 (julio-agosto): "Inteligencia ambiental". Editores invitados:Julio AbascalJulio AbascalJulio AbascalJulio AbascalJulio Abascal y Alberto LafuenteAlberto LafuenteAlberto LafuenteAlberto LafuenteAlberto Lafuente (Universidad del País Vasco).

Nº 189 (septiembre-octubre) "Dirección de proyectos TIC" Editorinvitado: Julián Marcelo Julián Marcelo Julián Marcelo Julián Marcelo Julián Marcelo (Universidad Politécnica de Valencia).

novática nº 184 noviembre-diciembre 2006 77asuntos interiores

asun

tos

inte

riore

ssocios institucionales de atiSegún los Estatutos de ATI, pueden ser socios institucionales de nuestra asociación"las personas jurídicas, públicas y privadas, que lo soliciten a la Junta DirectivaGeneral y sean aceptados como tales por la misma".

Mediante esta figura asociativa, todos los profesionales y directivos informáticosde los socios institucionales pueden gozar de los beneficios de participar en lasactividades de ATI, en especial congresos, jornadas, cursos, conferencias,charlas, etc. Asimismo los socios institucionales pueden acceder en condicionesespeciales a servicios ofrecidos por la asociación tales como Bolsa de Trabajo,cursos a medida, mailings, publicidad en Novática, servicio ATInet, etc.

Para más información dirigirse a <info@ati.es> o a cualquiera de las sedes deATI. En la actualidad son socios institucionales de ATI las siguientes empresasy entidades:

AGENCIA DE INFOR. Y COMUN. COMUNIDAD DE MADRIDAGROSEGURO, S.A.AIGÜES TER LLOBREGATAJUNTAMENT DE L'HOSPITALET DE LLOBREGATAJUNTAMENT DE TERRASSAALMIRALL PRODESFARMA, S.A.AMIGANEWBARCELÓ CORPORACIÓN EMPRESARIAL, S.A.BBR INGENIERÍA DE SERVICIOS, S.L.BURKE FORMACION, S.A.CÁLCULO, S.A.CCS PROFESIONALES, S.L.CENTRO DE ESTUDIOS VELAZQUEZ S.A. (C.E. Adams)CHOICE, S.A.CLASE 10 SISTEMAS, S.L.CLAU INFORMATICA, S.L.CONSULTORES SAYMA, S.A.COVERIUS (Correduría de Seguros)DEPARTAMENT D´ENSENYAMENT DE LA GENERALITATDIMENSIÓN INFORMATICA, S.L.EDITORIAL BELLADONA S.L.ELOGOS, S.A.ENDITEL-ENDESA INGENIERIA DE TELECOMUNICACIONESEPISER, S.L.ESPECIALIDADES ELÉCTRICAS, S.A. (ESPELSA)ESTEVE QUÍMICA, S.A.FUNDACIÓ CATALANA DE L´ESPLAIFUNDACIÓN SAN VALEROGRUPO BAMESAGRUPO CORPORATIVO GFI INFORMÁTICA, S.A.GRUPO INFORMÁTICO ITEM, S.A.GS y C, GABINETE S. CONSULT., S.L.IN2INFORMÁTICA Y COMUNICACIONES AVANZADAS, S.L.INQA TEST LABS, S.L.INSTITUT D'ESTUDIS CATALANSINSTITUT MUNICIPAL D´INFORMÀTICAINVERAMAJ.C. SERVEIS INFORMÁTICS, S.L.KRITER SOFTWARE, S.L.LABORATORIOS SERONO, S.A.LISP, S.L.METASINCRONTR - NET TRANSMIT & RECEIVE, S.L.OCCIDENTAL HOTELES MANAGEMENT, S.A.ONDATA INTERNATIONAL, S.L.PRACTIA CONSULTING, S.L.RCM SOFTWARE, S.L.RD SISTEMAS, S.A.RENAULT FINANCIACIÓN S.A.SADIEL, S.A.SANS BRANDEDAPPAREL,S.L.SCATI LABS, S.A.SERTECNET VALENCIASISTEMAS TÉCNICOS LOTERIAS ESTADO (STL)SOCIEDAD DE REDES ELECTRÓNICAS Y SERVICIOS, S.A.SOGETI ESPAÑA, S.L.SOLUCIONES INFORMÁTICAS PARA EL COMERCIO, S.L.SOPORTES, SISTEMAS, SOFTWARE, S.L.TATUM CONSULTING GROUP, S.A.TCP SISTEMAS INGENIERÍA, S.L.TECNOLOGIA Y CALIDAD DE SOFTWARE, S.A.T-SYSTEMS ITC Services España S.A.UNIVERSIDAD ANTONIO DE NEBRIJAUNIVERSIDAD DE EXTREMADURA - E. POLITÉCNICA DE CÁCERESUNIVERSITAT OBERTA DE CATALUNYA

normas de publicaciónpara autores

Febrero 2006

NováticaNováticaNováticaNováticaNovática agradece su contribución desinteresada a los miles de autores quehan elegido y elegirán sus páginas para presentar sus aportaciones al avanceprofesional y tecnológico de la Informática.

PeriodicidadPeriodicidadPeriodicidadPeriodicidadPeriodicidad: NováticaNováticaNováticaNováticaNovática tiene periodicidad bimestral y aparece los meses defebrero, abril, junio, septiembre, octubre y diciembre, salvo retrasos debidosa causas de fuerza mayor. El cierre de la edición es habitualmente un mesantes de la fecha de distribución (dos meses para los artículos del bloquemonográfico).

Normas de revisión:Normas de revisión:Normas de revisión:Normas de revisión:Normas de revisión: todos los artículos serán sometidos a un proceso de"revisión por iguales" (peer review), o revisión por personas especializadas enla materia objeto del artículo, excepto los expresamente solicitados porNováticaNováticaNováticaNováticaNovática a sus autores. En el caso de las monografías, serán los editoresinvitados y su equipo los que realicen la revisión y decidan sobre supublicación o no. Excepto en el caso de las monografías, los artículosdeberán ser enviados a la oficina de Coordinación Editorial (Novática-ATI.Calle Padilla 66, 3ª dcha., 28006 Madrid, <novatica@ati.es> (ver "Soportes"más abajo). Una vez aprobados por el revisor(es), serán publicados tanpronto como sea posible, si bien la publicación no está garantizada puesrazones de exceso de material pueden hacerla imposible. Los autores seráninformados del resultado de la revisión y de la publicación o no de losartículos remitidos.

Tamaño y formato de los artículos: Tamaño y formato de los artículos: Tamaño y formato de los artículos: Tamaño y formato de los artículos: Tamaño y formato de los artículos: Los artículos deberán tener un máximode 3.000 palabras, incluyendo resumen (máximo 20 líneas), palabras clave(un máximo de 10), tablas, figuras, bibliografía y notas. Sólo en casosexcepcionales se aceptarán artículos superiores a dicho tamaño. Salvoexcepciones, los artículos no deberán incluir más de cinco ecuaciones ni másde doce referencias bibliográficas o notas, y deberán incorporar,al principiodel mismo, título, nombre y dos apellidos y afiliación del autor/a (es/as), asícomo su dirección postal y electrónica, y números de teléfono y fax. Elartículo deberá ir en en formato Word, Open Office, RTF o HTML y habráde enviarse también en formato PDF para asegurar la fidelidad al original enel proceso de edición. La fuente utilizada deberá ser Times New Roman,tamaño 12, a doble espacio y es preciso además enviar las figuras porseparado, con la mayor resolución posible (mínimo 300 ppi), teniendo encuenta que solamente se publicarán en blanco y negro.

Nota importanteNota importanteNota importanteNota importanteNota importante: título, resumen y palabras clave deberán enviarse enespañol e inglés.

Soportes:Soportes:Soportes:Soportes:Soportes: Los artículos deberán ser enviados a Novática en formato digital,preferentemente mediante correo electrónico o, si no se tiene acceso a éste,mediante en disquete a través de correo postal. En caso de envío por correoelectrónico, si el fichero tiene un tamaño superior a 250KB, es preciso enviar elfichero comprimido con ZIP.

Lengua:Lengua:Lengua:Lengua:Lengua: aunque NováticaNováticaNováticaNováticaNovática admite artículos escritos en todas las lenguasreconocidas por la Constitución española y los Estatutos de las diferentesComunidades Autonómas, dado que el ámbito de difusión de la revistaconlleva su publicación en castellano, como lengua oficial común, losautores deberán presentar sus artículos en castellano y, si así lo desean, enotra lengua oficial de su elección. NováticaNováticaNováticaNováticaNovática enviará a los socios y suscriptoresque lo soliciten una copia de la versión original de aquellos artículos quehayan sido escritos en una lengua oficial que no sea el castellano.

Copyright:Copyright:Copyright:Copyright:Copyright: Novática Novática Novática Novática Novática da por supuesto que un autor acepta las presentes normasal enviar su original y que, en caso de que esté destinado a ser publicado en otromedio ajeno a ATI (o ya haya sido publicado) debe de aportar la autorizacióndel editor del mismo para su reproducción por NováticaNováticaNováticaNováticaNovática (incluida la autorizaciónpara realizar traducciones). NováticaNováticaNováticaNováticaNovática por tanto no asume ninguna responsabilidadsobre derechos de propiedad intelectual si un texto se ha publicado en otro mediode comunicación, sea inadvertidamente o no, por parte del autor. Todo autor quepublique un artículo en NováticaNováticaNováticaNováticaNovática debe saber que autoriza su reproducción,citando la procedencia, salvo que el autor utilice de forma explícita unamodalidad de © o copyright que lo impida. Asimismo, se entiende que el autoracepta que, además de en NováticaNováticaNováticaNováticaNovática, su artículo podrá ser también publicado ydistribuido de forma electrónica, en su totalidad o parcialmente, en los medioshabituales de difusión de ATI (servidor WWW, listas de distribución Internet,etc.) o en aquellos medios en los que ATI y NováticaNováticaNováticaNováticaNovática participen, como, porejemplo, UPUPUPUPUPGRADE o UPUPUPUPUPENET.

Estilo:Estilo:Estilo:Estilo:Estilo: si bien Novática Novática Novática Novática Novática respeta totalmente el estilo y contenido de cadaartículo, da por supuesta la autorización del autor para retocar su ortografía,léxico, sintaxis, titulación y paginación, a fin de facilitar su comprensión porel lector y de subsanar posibles errores. Cualquier cambio que afecte alcontenido será consultado con el autor.