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 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.