Los formatos de archivo Office Open XML son un conjunto de formatos de archivo que se pueden utilizar para representar documentos de oficina electrónicos. Existen formatos para documentos de procesamiento de textos , hojas de cálculo y presentaciones , así como formatos específicos para materiales como fórmulas matemáticas, gráficos, bibliografías, etc.
Los formatos fueron desarrollados por Microsoft y aparecieron por primera vez en Microsoft Office 2007 . Fueron estandarizados entre diciembre de 2006 y noviembre de 2008, primero por el consorcio Ecma International , donde se convirtieron en ECMA-376, y posteriormente, después de un polémico proceso de estandarización , por el Comité Técnico Conjunto 1 de ISO/IEC, donde se convirtieron en ISO/IEC 29500. :2008.
Los documentos de Office Open XML se almacenan en paquetes Open Packaging Conventions (OPC), que son archivos ZIP que contienen XML y otros archivos de datos, junto con una especificación de las relaciones entre ellos. [2] Dependiendo del tipo de documento, los paquetes tienen diferentes estructuras de directorios internos y nombres. Una aplicación utilizará los archivos de relaciones para localizar secciones (archivos) individuales, y cada una tendrá metadatos adjuntos, en particular metadatos MIME .
Un paquete básico contiene un archivo XML llamado [Content_Types].xml en la raíz, junto con tres directorios: _rels , docProps y un directorio específico para el tipo de documento (por ejemplo, en un paquete de procesamiento de textos .docx, habría un directorio de palabras ). El directorio de Word contiene el archivo document.xml , que es el contenido principal del documento.
Un archivo de relación de ejemplo ( word/_rels/document.xml.rels ) es:
<?xml versión="1.0" codificación="UTF-8" standalone="yes" ?> <Relaciones xmlns= "http://schemas.microsoft.com/package/2005/06/relationships" > < Id. de relación= "rId1" Type= "http://schemas.microsoft.com/office/2006/relationships/image" Target= "http://en.wikipedia.org/images/wiki-en.png" TargetMode= "Externo" /> < Id. de relación= "rId2" Tipo= "http://schemas.microsoft.com/office/2006/relationships/hyperlink" Target= "http://www.wikipedia.org" TargetMode= "Externo" /> </Relaciones> Como tal, las imágenes a las que se hace referencia en el documento se pueden encontrar en el archivo de relaciones buscando todas las relaciones que sean de tipo http://schemas.microsoft.com/office/2006/relationships/image. Para cambiar la imagen utilizada, edite la relación.
El siguiente código muestra un ejemplo de marcado en línea para un hipervínculo :
<w:hipervínculo r:id= "rId2" w:history= "1" xmlns:r= "http://schemas.openxmlformats.org/officeDocument/2006/relationships" xmlns:w= "http://schemas. openxmlformats.org/wordprocessingml/2006/main" > En este ejemplo, el localizador uniforme de recursos (URL) está en el atributo de destino de la relación a la que se hace referencia a través del ID de relación, "rId2" en este caso. Se hace referencia a las imágenes, plantillas y otros elementos vinculados de la misma manera.
Las imágenes se pueden incrustar o vincular mediante una etiqueta:
<v:imagedata w:rel= "rId1" o:title= "ejemplo" /> Esta es la referencia al archivo de imagen. Todas las referencias se gestionan a través de relaciones. Por ejemplo, un documento.xml tiene una relación con la imagen. Hay un directorio _rels en el mismo directorio que document.xml, dentro de _rels hay un archivo llamado document.xml.rels. En este archivo habrá una definición de relación que contiene tipo, ID y ubicación. El ID es el ID al que se hace referencia y que se utiliza en el documento XML. El tipo será una definición de esquema de referencia para el tipo de medio y la ubicación será una ubicación interna dentro del paquete ZIP o una ubicación externa definida con una URL.
Office Open XML utiliza el conjunto de elementos de metadatos Dublin Core y los términos de metadatos DCMI para almacenar propiedades de documentos. Dublin Core es un estándar para la descripción de recursos de información entre dominios y está definido en ISO 15836:2003.
Un archivo de propiedades de documento de ejemplo ( docProps/core.xml ) que utiliza metadatos Dublin Core es:
<?xml versión="1.0" codificación="UTF-8" standalone="yes"?> <cp:coreProperties xmlns:cp= "http://schemas.openxmlformats.org/package/2006/metadata/core-properties " xmlns:dc= "http://purl.org/dc/elements/1.1/" xmlns:dcterms= "http://purl.org/dc/terms/" xmlns:xsi= "http://www. w3.org/2001/XMLSchema-instance" > <dc:title> Office Open XML </dc:title> <dc:subject> Formato y estructura del archivo </dc:subject> <dc:creator> Wikipedia </dc: creador> <cp:keywords> Office Open XML, metadatos, Dublin Core </cp:keywords> <dc:description> Office Open XML utiliza ISO 15836:2003 </dc:description> <cp:lastModifiedBy> Wikipedia </cp: lastModifiedBy> <cp:revision> 1 </cp:revision> <dcterms:created xsi:type= "dcterms:W3CDTF" > 2008-06-19T20:00:00Z </dcterms:created> <dcterms:modified xsi:type = "dcterms:W3CDTF" > 2008-06-19T20:42:00Z </dcterms:modified> <cp:category> Formato de archivo de documento </cp:category> <cp:contentStatus> Final </cp:contentStatus> </ cp: propiedades principales> Un archivo Office Open XML puede contener varios documentos codificados en lenguajes de marcado especializados correspondientes a aplicaciones dentro de la línea de productos Microsoft Office. Office Open XML define varios vocabularios utilizando 27 espacios de nombres y 89 módulos de esquema .
Los principales lenguajes de marcado son:
Los materiales de lenguaje de marcado compartidos incluyen:
Además de los lenguajes de marcado anteriores, se pueden utilizar esquemas XML personalizados para ampliar Office Open XML.
Patrick Durusau, editor de ODF , ha considerado que el estilo de marcado de OOXML y ODF representa dos lados de un debate: el "lado del elemento" y el "lado del atributo". Señala que OOXML representa "el lado del elemento de este enfoque" y destaca el KeepNextelemento como ejemplo:
<w:pPr> <w:keepNext/> … </w:pPr> Por el contrario, señala que ODF usaría el atributo único fo:keep-next, en lugar de un elemento, para la misma semántica. [3]
El esquema XML de Office Open XML hace hincapié en reducir el tiempo de carga y mejorar la velocidad de análisis . [4] En una prueba con aplicaciones actuales en abril de 2007, los documentos de Office basados en XML se cargaron más lentamente que los formatos binarios. [5] Para mejorar el rendimiento, Office Open XML utiliza nombres de elementos muy cortos para los elementos comunes y las hojas de cálculo guardan las fechas como números de índice (a partir de 1900 o de 1904). [6] Para ser sistemático y genérico, Office Open XML normalmente usa elementos secundarios separados para datos y metadatos (nombres de elementos que terminan en Pr para propiedades ) en lugar de usar múltiples atributos, lo que permite propiedades estructuradas. Office Open XML no utiliza contenido mixto, pero utiliza elementos para colocar una serie de ejecuciones de texto (nombre de elemento r ) en párrafos (nombre de elemento p ). El resultado es conciso [ cita necesaria ] y altamente anidado en contraste con HTML , por ejemplo, que es bastante plano, diseñado para que los humanos escriban en editores de texto y es más agradable para que los humanos lo lean.
La denominación de elementos y atributos dentro del texto ha suscitado algunas críticas. Hay tres sintaxis diferentes en OOXML (ECMA-376) para especificar el color y la alineación del texto dependiendo de si el documento es un texto, una hoja de cálculo o una presentación. Rob Weir ( empleado de IBM y copresidente del CT OASIS OpenDocument Format ) pregunta: "¿Cuál es la justificación técnica para este horror?". Contrasta con OpenDocument : "ODF utiliza el vocabulario XSL-FO del W3C para el estilo del texto y utiliza este vocabulario de forma coherente". [7]
Algunos han argumentado que el diseño se basa demasiado en las aplicaciones de Microsoft. En agosto de 2007, la Fundación Linux publicó una entrada de blog pidiendo a los organismos nacionales ISO que votaran "No, con comentarios" durante la estandarización internacional de OOXML. Decía: "OOXML es una adaptación directa de los formatos de documentos binarios de un único proveedor. Evita la reutilización de estándares internacionales relevantes existentes (por ejemplo, varios algoritmos criptográficos, VML, etc.). Hay literalmente cientos de fallas técnicas que deberían corregirse. abordados antes de estandarizar OOXML, incluido el uso continuo de código binario vinculado a características específicas de la plataforma, la propagación de errores en MS-Office en las unidades estándar, propietarias, referencias a etiquetas propietarias/confidenciales, derechos de propiedad intelectual y patentes poco claros, y mucho más". [8]
La versión del estándar presentada al JTC 1 tenía 6546 páginas. Se ha cuestionado la necesidad e idoneidad de tal extensión. [9] [10] Google afirmó que "el estándar ODF, que logra el mismo objetivo, tiene sólo 867 páginas" [9]
Los documentos de procesamiento de textos utilizan el vocabulario XML conocido como WordprocessingML definido normativamente por el esquema wml.xsdque acompaña al estándar. Este vocabulario se define en la cláusula 11 de la Parte 1. [11]
Los documentos de hoja de cálculo utilizan el vocabulario XML conocido como SpreadsheetML definido normativamente por el esquema sml.xsdque acompaña al estándar. Este vocabulario se describe en la cláusula 12 de la Parte 1. [11]
Cada hoja de cálculo en una hoja de cálculo está representada por un documento XML con un elemento raíz nombrado <worksheet>...</worksheet>en el http://schemas.openxmlformats.org/spreadsheetml/2006/main Namespace.
La representación de los valores de fecha y hora en SpreadsheetML ha generado algunas críticas. ECMA-376 1.ª edición no cumple con la norma ISO 8601:2004 "Representación de fechas y horas". Requiere que las implementaciones repliquen un error de Lotus 1-2-3 [12] que trata erróneamente a 1900 como un año bisiesto. Los productos que cumplan con ECMA-376 deberían utilizar la función de hoja de cálculo WEEKDAY() y, por lo tanto, asignar fechas incorrectas a algunos días de la semana y también calcular mal el número de días entre ciertas fechas. [13] ECMA-376 2ª edición (ISO/IEC 29500) permite el uso de 8601:2004 "Representación de fechas y horas" además del formulario compatible con errores Lotus 1-2-3. [14] [15]
Office Math Markup Language es un lenguaje de marcado matemático que se puede incrustar en WordprocessingML, con soporte intrínseco para incluir marcado de procesamiento de textos como marcas de revisión, [16] notas al pie, comentarios, imágenes y formatos y estilos elaborados. [17] El formato OMML es diferente de la recomendación MathML del World Wide Web Consortium (W3C) que no admite esas características de oficina, pero es parcialmente compatible [18] a través de Transformaciones XSL ; Las herramientas se proporcionan con la suite ofimática y se utilizan automáticamente mediante transformaciones del portapapeles. [19]
El siguiente ejemplo de Office MathML define la fracción :
<m:oMathPara> <!-- contenedor de bloques matemáticos utilizado como párrafo --> <m:oMath> <!-- fórmula matemática en línea --> <m:f> <!-- una fracción --> <m :num><m:r><m:t> π </m:t></m:r></m:num> <!-- numerador que contiene una sola ejecución de texto --> <m:den ><m:r><m:t> 2 </m:t></m:r></m:den> <!-- denominador que contiene una sola ejecución de texto --> </m:f> </m:oMath> </m:oMathPara> Algunos han cuestionado la necesidad de Office MathML (OMML) y en su lugar abogan por el uso de MathML , una recomendación del W3C para la "inclusión de expresiones matemáticas en páginas web" y la "comunicación de máquina a máquina". [20] Murray Sargent ha respondido algunas de estas cuestiones en una publicación de blog, que detalla algunas de las diferencias filosóficas entre los dos formatos. [21]
DrawingML es el lenguaje de marcado de gráficos vectoriales utilizado en documentos Office Open XML. Sus características principales son la representación gráfica de elementos de texto, elementos de formas gráficos basados en vectores, tablas y cuadros gráficos.
La tabla DrawingML es el tercer modelo de tabla en Office Open XML (junto a los modelos de tabla en WordprocessingML y SpreadsheetML) y está optimizada para efectos gráficos y su uso principal es en presentaciones creadas con el marcado PresentationML. DrawingML contiene efectos gráficos (como sombras y reflejos) que se pueden usar en los diferentes elementos gráficos que se usan en DrawingML. En DrawingML también puedes crear efectos 3D, por ejemplo para mostrar los diferentes elementos gráficos a través de un punto de vista de cámara flexible. Es posible crear partes del tema DrawingML independientes en un paquete Office Open XML. Estos temas luego se pueden aplicar a elementos gráficos en todo el paquete Office Open XML. [22]
DrawingML no está relacionado con otros formatos de gráficos vectoriales como SVG . Estos se pueden convertir a DrawingML para incluirlos de forma nativa en un documento Office Open XML. Este es un enfoque diferente al del formato OpenDocument , que utiliza un subconjunto de SVG e incluye gráficos vectoriales como archivos separados.
Las dimensiones de un gráfico DrawingML se especifican en unidades métricas inglesas (EMU). Se llama así porque permite una representación común exacta de las dimensiones originalmente en unidades inglesas o métricas , definidas como 1/360.000 de centímetro , y por lo tanto hay 914.400 EMU por pulgada y 12.700 EMU por punto , para evitar el redondeo. en los cálculos. Rick Jelliffe favorece las UEM como una solución racional a un conjunto particular de criterios de diseño. [23]
Algunos han criticado el uso de DrawingML (y el VML de solo uso transitorio ) en lugar del SVG recomendado por el W3C . [24] VML no se convirtió en una recomendación del W3C. [25]
Los documentos OOXML suelen estar compuestos por otros recursos además del contenido XML (gráficos, vídeos, etc.).
Algunos han criticado la elección del formato permitido para dichos recursos: ECMA-376 1.ª edición especifica "Tipos de solicitudes de imágenes alternativas de objetos incrustados" y "Tipos de formato del portapapeles", que se refieren a metarchivos de Windows o metarchivos mejorados , cada uno de los cuales son formatos propietarios que tienen dependencias codificadas en el propio Windows . Los críticos afirman que el estándar debería haber hecho referencia al estándar neutral de plataforma ISO/IEC 8632 " Metarchivo de gráficos por computadora ". [13]
El Estándar proporciona tres mecanismos para permitir que se incorporen marcas extranjeras en el contenido con fines de edición:
Estos se definen en la cláusula 17.5 de la Parte 1.
Las versiones de Office Open XML contienen lo que se denomina "configuraciones de compatibilidad". Estos están contenidos en la Parte 4 ("Referencia del lenguaje de marcado") de ECMA-376 1.ª edición, pero durante la estandarización se trasladaron para convertirse en una nueva parte (también llamada Parte 4) de ISO/IEC 29500:2008 ("Características de migración de transición") .
Estas configuraciones (incluidos elementos con nombres como autoSpaceLikeWord95 , footnoteLayoutLikeWW8 , lineWrapLikeWord6 , mwSmallCaps , shapeLayoutLikeWW8 , suprimirTopSpacingWP , truncateFontHeightsLikeWP6 , uiCompat97To2003 , useWord2002TableStyleRules , useWord97LineBreakRules , wpJustification y wpSpaceWidth ) fueron el foco de cierta controversia durante la estandarización de DIS 29500. [26] Como Como resultado, se agregó un nuevo texto a ISO/IEC 29500 para documentarlos. [27]
Un artículo en la revista Free Software ha criticado el marcado utilizado para estas configuraciones. Office Open XML utiliza elementos con nombres distintos para cada configuración de compatibilidad, cada uno de los cuales se declara en el esquema. Por lo tanto, el repertorio de configuraciones es limitado: para agregar nuevas configuraciones de compatibilidad, es posible que sea necesario declarar nuevos elementos, "creando potencialmente miles de ellos, cada uno de los cuales no tiene nada que ver con la interoperabilidad". [28]
El estándar proporciona dos tipos de mecanismo de extensibilidad, compatibilidad y extensibilidad de marcado (MCE) definidas en la Parte 3 (ISO/IEC 29500-3:2008) y Listas de extensión definidas en la cláusula 18.2.10 de la Parte 1.
Si ISO le diera a OOXML con sus 6546 páginas el mismo nivel de revisión que otros estándares han tenido, se necesitarían 18 años (6576 días para 6546 páginas) para lograr niveles de revisión comparables al estándar ODF existente (871 días para 867 páginas). ) que logra el mismo propósito y, por tanto, es una buena comparación. Teniendo en cuenta que OOXML sólo ha recibido alrededor del 5,5% de las revisiones que han sufrido estándares comparables, los informes sobre inconsistencias, contradicciones e información faltante no son sorprendentes.
"... OOXML eligió esta ruta. En lugar de crear una etiqueta de configuración definible por la aplicación, hay una etiqueta única para cada configuración... Actualmente, las únicas configuraciones únicas de la aplicación que se atienden son las aplicaciones que los autores del estándar han decidido incluir, ... Para agregar otras aplicaciones, sería necesario definir más nombres de etiquetas en la especificación, creando potencialmente miles de ellas, cada una de las cuales no tiene nada que ver con la interoperabilidad ... ".