Libro - Blanco XBRL

NDICE
Prlogo Prlogo a la primera edicin
1 Introduccin 1 Introduccin
7 7 8 8 10 10 12 12 13 13
13 14 15
2 Objetivos del documento 2 Objetivos del documento 3 XML y XBRL. nceptos bsicos 3 XML y XBRL. Conceptos bsicos
3.1 XML como lenguaje universal 3.2 Necesidades de un lenguaje estndar de reporting empresarial 3.3 XBRL como un lenguaje de etiquetado expresando reglas 4.1 Especificacin XBRL versin 2.1 4.1.1 Descripcin de la especificacin XBRL versin 2.1 4.1.2 Informes XBRL 4.1.3 Taxonomas XBRL 4.1.4 Referencias 4.2 Almacenamiento 4.2.1 Almacenamiento XML/XBRL 4.2.2 Lenguajes de consulta XML 4.3 Envo y recepcin de informes XBRL 4.4 Recepcin de informacin y tratamiento 4.5 Seguridad 4.5.1 Seguridad en el aplicativo 4.5.2 Seguridad en la instancia generada 4.5.3 Seguridad en la transmisin de las instancias 4.5.4 Soluciones para el canal de comunicacin 4.5.5 Herramientas 4.5.6 Bibliografa 4.6 Arquitectura XBRL 4.6.1 Arquitectura de referencia 4.6.2 Rendimiento 4.7 Dimensiones 4.8 Frmulas 4.9 Versionado
4 XBRL. Conceptos y recomendaciones 4 XBRL. Conceptos y recomendaciones
16 16 19 24 30 31 31 48 50 54 56 56 58 60 62 67 68 69 69 73 76 87 104
16 16
5 Productos y Servicios 5 Productos y Servicios 6 Formacin 6 Formacin

6.1 Tecnologas 6.2 Tecnologas de Manipulacin XML 6.3 Esquema de Aprendizaje
106 106 106 106

110 111 112 113
7 Material de referencia y ejemplos 7 Material de referencia y ejemplos
7.1 Esquema general de casos de uso e implementacin de un sistema XBRL siguiendo una arquitectura orientada a servicios
113 113
Prlogo
Cualquier cambio, conlleva un proceso de elaboracin de lo diferente, una adaptacin a lo nuevo, si a esto unimos que XBRL (eXtensible Business Reporting Language) es un estndar que afecta a sectores especialmente sensibles como el financiero y el bancario, nos encontramos ante un escenario especialmente complejo. Pero sin duda, si echamos la vista atrs y realizamos un anlisis de lo acontecido, podemos afirmar que el XBRL ha pasado de ser un ente abstracto a convertirse en una realidad. Hemos pasado de un marco XBRL terico a implementaciones concretas en el mundo real, cada da podemos aadir ms instituciones y compaas que se unen a la utilizacin de este estndar. Hemos podido comprobar la aparicin de nuevas taxonomas como LENLOC, ES-BE-COREP, ES-BE-CB, DGI Tambin se ha avanzado en la aprobacin por parte del grupo de tecnologa de una primera estrategia de versionado de las taxonomas, que resuelve el siempre importante y crtico problema de la compatibilidad entre versiones.
Han pasado casi dos aos desde que con mucho esfuerzo e ilusin se present la primera edicin de este libro. Con la facilidad didctica que le caracteriza, Don Enrique Bonsn Ponte expona en su prlogo los avances que este nuevo estndar, llamado a la revolucin del intercambio de informacin financiera, haba ido sufriendo desde su aparicin all por el ao 1998.
El continuo avance en las herramientas de conversin, validacin y sobre todo visualizacin dentro del entorno de XBRL, ha permitido separar los aspectos ms tcnicos de la lgica de negocio, acercando el uso de este estndar a usuarios sin un gran conocimiento de la tecnologa empleada.
Para finalizar, no me gustara pasar por alto un agradecimiento especial al desinteresado esfuerzo que estn realizando los miembros de la Asociacin XBRL Espaa, sin ellos este libro no sera posible, y aprovechar la oportunidad para animar a todos aquellos que an no formis parte de la asociacin a uniros a este gran proyecto que crece da a da.
Enrique Muoz Garca

Director Relaciones Institucionales Informtica El Corte Ingls.
Enrique Muoz Garca
Prlogo a la primera edicin
Los avances tecnolgicos de las ltimas dcadas han configurado un nuevo escenario digital para la informacin financiera. Ahora bien, digital no quiere decir compatible, por lo que un documento (balance, cuenta de resultados, etc.) generado por un programa informtico determinado no es directamente legible por otro programa distinto. Esto es debido a que cada fabricante utiliza sus propios formatos de almacenamiento de datos.
La solucin tradicional a este problema ha sido la exportacin del fichero deseado a formato ASCII (fichero de texto en el que cada campo de informacin se separa del siguiente por medio de caracteres delimitadores), para, posteriormente, recuperar el fichero ASCII desde el programa que va a incorporar los datos. Con esta solucin, se producen prdidas de tiempo debido a que porque es frecuente tener que realizar ciertas modificaciones en el fichero ASCII, debido a que llos delliimiitadores que genera ell programa exportador no siiempre son reconociidos por ell os de m tadores que genera e programa exportador no s empre son reconoc dos por e programa que rea za a mportac n, y esto puede provocar desp azam entos en as tabu a programa que realliiza lla iimportaciin, y esto puede provocar despllazamiientos en llas tabulla-c ones de datos. ciiones de datos. Otra solucin es disear un programa especfico capaz de realizar la conversin La necesidad de un estndar digital para el intercambio de informacin contable entre aplicaciones de software se acenta si de lo que se trata es de integrar mltiples datos procedentes de de datos entre dos aplicaciones, pero la solucin ideal es la utilizacin de un estndar para el intercambio.
En Espaa, el XBRL es introducido en 2001 por AECA (Asociacin Espaola de Contabilidad y Administracin de Empresas) que, a travs de su Comisin de Nuevas Tecnologas y Contabilidad, comienza a estudiar el estndar y sus posibilidades de utilizacin oficial, que incorpora todos los elementos de informacin que las empresas cotizadas remiten peridicamente a la CNMV, la PGC90 (Plan General Contable de 1990) que contendr todos los elementos de las cuentas anuales del Plan General de Contabilidad de 1990 y las taxonomas coordinadas por el Banco de Espaa (informacin remitida por las sociedades y servicios de tasacin; Informacin financiera por parte de las entidades de crdito y sistema de intercambio de informacin financiera; COREP, Common Reporting, del Comit Europeo de Supervisores Bancarios y SEPBLAC, Servicio Ejecutivo de la Comisin para la Prevencin del Blanqueo de Capitales e infracciones monetarias).
Accountants in England and Wales).
CICA (Canadian Institute of Chartered Accountants) o el ICAEW (Institute of Chartered
(Internacional Accounting Standards Board), el IMA (Institute of Management Accountants), el
estados financieros publicados en diversos formatos (pdf, xls, html, doc, etc.). Ese estndar es hoy el XBRL, estndar ampliamente aceptado por la comunidad contable internacional, desarrollado por XBRL.org, un consorcio internacional de empresas y organizaciones, patrocinado por el AICPA (American Institute of Certified Public Accountants), entre las que se encuentran las grandes de la informtica, de la contabilidad y la consultora, e instituciones como el IASB
En este libro, elaborado por el grupo de trabajo de tecnologa de la Asociacin XBRL Espaa, se recogen los aspectos fundamentales del estndar de una forma clara y concisa. En l se abordan las principales cuestiones que cualquier lector interesado necesita conocer para comprender el alcance y las implicaciones del XBRL, por ejemplo los conceptos bsicos, la especificacin v2.1, la generacin y/o captura de informacin XBRL, las taxonomas, el control de errores y la validacin de informes, el envo, recepcin y almacenamiento de informes XBRL, la recepcin de informacin y su tratamiento, la seguridad, el versionado o los productos y servicios XBRL por citar algunas. En definitiva se trata de un excelente documento de referencia -el primero de estas caractersticas escrito en castellano- de obligada lectura no slo para los profesionales responsables de la adopcin e implantacin del XBRL en sus empresas u organizaciones, sino tambin para todos los que necesiten conocer los fundamentos de este estndar para el intercambio de informacin de creciente difusin dentro de la comunidad financiera internacional.
miembros del grupo de tecnologa de la Asociacin, que han hecho posible que este documento sea una realidad. A todos ellos, muchas gracias.
Para finalizar estas lneas, me gustara destacar el desinteresado esfuerzo realizado por los
Huelva, Junio de 2005
Enrique Bonsn Ponte

Catedrtico de Economa Financiera y Contabilidad de la Universidad de Huelva. Vicepresidente de XBRL Espaa.
Vicepresidente de XBRL Espaa.
Enrique Bonsn Ponte
1 1
La adopcin del estndar XBRL para la presentacin de informacin financiera y empresarial por parte de una entidad requiere siempre un esfuerzo, ya que supone integrar una nueva tecnologa en los sistemas de informacin existentes en la entidad. Este esfuerzo vara mucho dependiendo del grado de integracin de XBRL en los mencionados sistemas, y va desde la simple preparacin de un informe de acuerdo con una taxonoma elaborada por otra entidad, a una profunda reestructuracin de procesos o de sistemas, pasando por el desarrollo, aprobacin y publicacin de taxonomas. Muchas entidades habituadas a trabajar con XML, no van a ver XBRL como algo especialmente novedoso, ya que se trata de una particularizacin de XML, pero otras seguramente agradecern un libro como ste que les facilite el primer contacto con el estndar. Este libro ha sido el primer trabajo abordado por el grupo de Tecnologa de XBRL Espaa y se ha pretendido recoger en l las respuestas a las principales preguntas que se plantea el futuro usuario de este estndar universal para intercambio de informes. En el captulo 3 del libro se presenta XBRL como un lenguaje de etiquetado de datos que responde a las necesidades de un lenguaje estndar de cobertura universal para la elaboracin de informes empresariales. Se incluyen en el captulo los conceptos bsicos de XML y XBRL y se sealan las particularidades que los diferencian.
Introduccin
El captulo 6 est dedicado a la formacin, pero slo con la idea de informar sobre los mnimos conocimientos que deberan poseer los tcnicos de un equipo que se proponga abordar un proyecto XBRL. En este captulo se incluye una referencia al documento de Formacin y Buenas Prcticas, preparado por el grupo de trabajo de Desarrollo y Formacin de XBRL Espaa, en el que s se estudian en profundidad los requisitos de formacin y la forma de desarrollar un proyecto de este tipo. 6
El captulo 5 contiene un relacin de soluciones y herramientas existentes en el mercado, tanto para desarrollo de taxonomas como para la elaboracin y manejo de informes XBRL, indicando sus caractersticas y prestaciones.
En el captulo 4 se amplan los conceptos XBRL detallndose los elementos que componen una taxonoma y los que componen un informe XBRL. Se tratan las distintas posibilidades de envo, recepcin, almacenamiento y recuperacin de informes XBRL y se facilita una arquitectura funcional y tcnica de implantacin de XBRL para que sirva de referencia. Como elemento imprescindible de control en el desarrollo y mantenimiento de una taxonoma, se incluyen unas indicaciones sobre buenas prcticas de versionado. Tambin se hacen consideraciones sobre rendimiento de aplicaciones XBRL y se dan recomendaciones para optimizar ese rendimiento. Aunque la seguridad es algo que est fuera de la especificacin XBRL, se ha credo interesante tratar tambin en este captulo los aspectos de seguridad en la generacin, almacenamiento y envo de informes.
La versin en red de este libro puede tambin encontrarse en www.xbrl.org.es donde se publicarn as mismo las actualizaciones peridicas correspondientes.
Finalmente, el captulo 7 contiene algunos ejemplos de implantacin de XBRL que pueden servir de referencia a los nuevos usuarios de este estndar.
Este Libro Blanco pretende facilitar a todos los interesados en el estndar XBRL el primer acercamiento a esta tecnologa. Es objetivo del libro mitigar el miedo a lo desconocido y aportar una serie de datos y recomendaciones tiles para cualquier entidad que se plantee implantar XBRL. Puede resultar de especial inters para los tcnicos que pretendan iniciar un proyecto XBRL de cualquier tipo, ya que en l pueden encontrar una referencia a todos los componentes tecnolgicos que van a necesitar.
2 2 Objetivos del documento
Ha sido una preocupacin constante en el desarrollo del libro el elaborar un documento completo, que aportara toda la informacin imprescindible, presentando con claridad los conceptos que se manejan en el mundo XBRL, pero que al mismo tiempo resultara fcil de leer, incluso para los no familiarizados con la materia. Intencionadamente se ha evitado profundizar mucho en los distintos temas, optndose, por el contrario, por incluir muchas referencias externas a documentos y sedes web donde el lector interesado puede ampliar sus conocimientos hasta el extremo que desee.
3.1 XML como lenguaje universal
3 3 XML y XBRL. Conceptos bsicos
XML, acrnimo de eXtensible Markup Language o Lenguaje de Marcado Extendido, es un lenguaje de marcado universal y estndar, definido por el World Wide Web Consortium, W3C, para el formateo de informacin etiquetada.
Ejemplo 1: La informacin ordinaria se acota entre etiquetas para dotarlas de significado adicional
El formato de etiquetas XML proporciona un significado adicional a la informacin ordinaria a intercambiar de forma que las aplicaciones informticas que consumen la informacin sean capaces de entender dicho significado, son los llamados metadatos de las etiquetas.
Como podemos observar en el ejemplo anterior una aplicacin informtica capaz de interpretar los metadatos de las etiquetas podra entender el nombre de la persona Michael M. Miller y distinguirlo separadamente de su direccin postal y, de esta forma, automatizar el procesamiento de estos datos. Desde su creacin en 1998, XML ha servido como base para la construccin de otros lenguajes segn diversos aspectos: - Orientados al intercambio y extraccin de informacin: SOAP, WSDL, XQuery, XPath, SAX, DOM. - Orientados a formar vocabularios especficos de negocio: MathML, MusicML, OTA, HL7, XBRL. - Orientados al formato o presentacin de la informacin: XHTML, XForms, WML, SVG. - Orientados a tratar y transformar el propio XML: XSLT, XSL-FO, XML-Schema, RelaxNG, XLink, XPointer.
3.2 Necesidades de un lenguaje estndar de reporting empresarial
Cuando se sentaron las bases para describir un lenguaje de reporting se pens en una sintaxis que alcanzase los siguientes requisitos:
- Basado en un formato universal y abierto: eXtensible Markup Language, XML - Que las definiciones de los metadatos a intercambiar sean definiciones estndar, es decir, que un trmino como por ejemplo caja y depsito en bancos centrales significase siempre lo mismo independientemente de las aplicaciones que usaran dicho trmino: ste es el pilar en el que se sustentan las taxonomas, diccionarios comunes de datos expresados en lenguaje XBRL. - Adems, otro requisito necesario es que estas taxonomas sean fcilmente extensibles de forma que diversas industrias, compaas y analistas fueran capaces de publicar definiciones a medida (siempre independientemente de las aplicaciones informticas). - Por ltimo, al no estar implementados en las aplicaciones informticas dichos diccionarios de conceptos, la forma de las colecciones de datos pueden variar, consiguiendo un lenguaje con el que expresar datos de calidad guiados por Reglas de Negocio, que puedan ser usados por distintas aplicaciones.
intercambio de informes empresariales, basado en XML y otros estndares del W3C complementando a XML, como son la especificacin de espacios de nombres (namespaces), la definicin de esquemas de datos en XML (XMLSchema) y la definicin de recursos enlazados mediante XML (XLink).
De esta forma, y tras varias revisiones desde 1998 hasta la fecha actual, se construye XBRL, eXtensible Business Reporting Language, como un lenguaje cuya sintaxis ha sido diseada para el
10
3.3 XBRL como un lenguaje de etiquetado expresando reglas

La motivacin de dotar al lenguaje etiquetado con reglas es la siguiente:
Para conseguir la extensibilidad y garantizar la unicidad en la definicin de los conceptos, el etiquetado de informacin XML no es suficiente. Hace falta poder aadir reglas a esa informacin.
*El significado de estos conceptos puede variar de acuerdo con los distintos principios contables que se apliquen al objeto de la informacin. **El nombre de otros conceptos idnticos de otra forma vara de una jurisdiccin a otra, por no mencionar la variacin en significado al cambiar de un idioma nativo a otro.
Para hacernos una idea de las reglas que definen estas relaciones, citaremos por ejemplo las siguientes:
Por tanto, en el lenguaje XBRL adicionalmente a la definicin de los conceptos a reportar se expresan unos metadatos de los propios conceptos de la taxonoma, esto son que las relaciones existentes entre los conceptos y se expresan mediante reglas con sintaxis XML. Son las llamadas linkbases, que se describen con ms detalle en el siguiente captulo.
- Definir relaciones de clculo simple entre dos conceptos: el concepto TotalEmpleados se obtiene como la suma entre el valor del concepto EmpleadosFijos con EmpleadosTemporales. - Relaciones de negocio. El concepto TotalCostesIndirectos es similar a TotalGastosIndirectos. - Relaciones de presentacin. Estableciendo dependencias jerrquicas que ayudan a la hora de entender la informacin reportada. - Definir relaciones entre conceptos y sus referencias en textos escritos, por ejemplo documentos legales, etc. - Establecer relaciones entre conceptos y distintos literales de texto que lo describan en diversos formatos e idiomas.
11
4.1 Especificacin XBRL versin 2.1

El documento utilizado para realizar esta edicin es:
4 4 XBRL. Conceptos y recomendaciones
4.1.1 Descripcin de la especificacin XBRL versin 2.1

XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2005-03-24.doc
Este documento es la base de XBRL versin 2.1. Ha sido realizado por la comunidad que compone el consorcio XBRL (subgrupo de especificacin) y se encuentra disponible en Internet en la pgina web http://www.xbrl.org. Captulo 1: Introduccin, en la que se comenta el propsito de la especificacin, la relacin con otros documentos, terminologa, niveles de conformidad con XBRL y los espacios de nombres utiLa especificacin est organizada en los siguientes captulos:
lizados en el resto del documento.
Captulo 2: Cambios respecto de la especificacin 2.0a. En este captulo se enumeran las diferencias entre las distintas versiones de XBRL, XBRL 2.0a y XBRL 2.1.
La especificacin 2.0a se describi en un documento de menos de cuarenta pginas, en algunos aspectos la especificacin 2.0a era muy abierta o demasiado flexible, lo cual llev a que ciertos editores de taxonomas creasen documentos vlidos de acuerdo a la especificacin, pero incompatibles entre s. La especificacin 2.0a ha estado viva durante un ao (2003), ya que a finales de dicho ao se aprob la nueva versin 2.1 que soluciona todos los problemas que se encontraron en los primeros proyectos de adopcin de XBRL.
Captulo 3: Entorno XBRL. Se analiza a continuacin el entorno en el que trabaja XBRL. En este captulo se describe por primera vez un informe y una taxonoma XBRL sin entrar a discutir los detalles. Se describe la funcin del DTS (Discoverable Taxonomy Set) lo cual es nuevo en XBRL 2.1 y se hace mencin explcita de la intencin de mantener separados los requerimientos de seguridad de las aplicaciones de la funcin de XBRL como formato para el contenido de informes empresariales. XBRL no impone, limita o impide el uso de cualquier otro mecanismo de seguridad que se requiera en cada momento. XBRL y seguridad son dos temas independientes y la especificacin, por tanto, no entra a discutir este entorno.
Los siguientes apartados de este captulo describen la validacin de documentos XBRL y de taxonomas, as como el uso de XLink en XBRL. XLink es una tecnologa basada en XML para 12
definir relaciones entre elementos que se encuentran en diferentes ficheros, de la misma forma que en HTML podemos definir enlaces entre documentos. La primera versin de XBRL (1.0), al igual que la mayora de los lenguajes basados en XML, presentaba una estructura jerrquica y anidada de elementos. Ejemplo 1: INFORME XBRL Versin 1.0 (ILUSTRATIVO)
<balance> <activo> <inmovilizado>1000</inmovilizado> <totalActivo>1000000</totalActivo> </activo> <pasivo> <capitalSocial>2000</capitalSocial> <totalPasivo>1000000</totalPasivo> </pasivo> </balance>
estructura del balance. No se podan definir fcilmente reglas de negocio que operasen con los valores de los elementos. Y tampoco fue nunca un requerimiento de negocio hacer coincidir la representacin de un balance con la estructura en XML. En definitiva, eran ms los problemas con los que nos encontrbamos por este camino que adoptando una estructura diferente. XBRL 2.1 presenta todos los datos en una estructura plana. Ejemplo 2: INFORME XBRL Versin 2.1 (ILUSTRATIVO)
Rpidamente se descubri que este sistema tena sus limitaciones. Slo se poda representar una
<inmovilizado>1000</inmovilizado> <totalActivo>1000000</totalActivo> <capitalSocial>2000</capitalSocial> <totalPasivo>1000000</totalPasivo> </xbrl>
<xbrl> <schemaRef xlink:href=taxonomia.xsd/>
13
Este informe se complementa con la informacin que aparece en la taxonoma donde se describen los elementos utilizados en el informe (inmovilizado, totalActivo, capitalSocial y totalPasivo), as como todas las posibles jerarquas entre elementos que los autores de la taxonoma quieran realizar.
Ejemplos de mltiples estructuras de relaciones entre los elementos pueden ser: formato de balance por orden de liquidez, balance segn el orden establecido en el plan de cuentas as como estructuras de clculo entre los elementos, etiquetas en mltiples idiomas y relaciones con los textos legales que ayuden a interpretar el significado y uso de los elementos y relaciones de dependencia entre los elementos.
La tecnologa que nos permitir relacionar los elementos en estas estructuras se denomina XLink. XLink aparece por primera vez en XBRL 2.0 y, desde entonces, se ha utilizado extensivamente en XBRL hasta el punto de que la especificacin XBRL tiene un captulo especfico explicando el uso de XLink en XBRL. No es probable que XBRL abandone el uso de XLink, dado que proporciona un mecanismo perfecto para relacionar informacin de la misma manera que las pginas web mantienen enlaces entre ellas.
14
4.1.2 Informes XBRL
El siguiente captulo de la especificacin trata en profundidad sobre el formato de los informes XBRL 2.1 y de sus posibilidades.
Es cierto que XBRL ha nacido en el seno de AICPA http://www.aicpa.org (la asociacin americana de censores y auditores de cuentas) y que el mayor avance en XBRL existe hoy en da para informacin financiera. Sin embargo, ya en el ao 1998 y 1999 XBRL se llam XFRML (eXtensible Financial Reporting Markup Language) el nombre actual (eXtensible Business Reporting Language) se adopt posteriormente, cuando se comprob que XBRL se puede utilizar no slo para la informacin financiera, sino para cualquier otro tipo de informes empresariales que se deseen modelar e intercambiar. ma correspondiente xbrl-instance-2003-12-31.xsd y muestra un informe de ejemplo que pasamos a describir a continuacin: Ejemplo 3: INFORME XBRL Versin2.1 Comienza la especificacin por mostrar cmo se ha definido el elemento <xbrl> en el esque-
Con XBRL se puede modelar cualquier tipo de informe empresarial. XBRL no est diseado para modelar informacin financiera exclusivamente. La especificacin XBRL 2.1 no presupone que se vaya a representar ningn tipo de informe en concreto.
<xbrl xmlns=http://www.xbrl.org/2003/instance xmlns:xlink=http://www.w3.org/1999/xlink xmlns:link=http://www.xbrl.org/2003/linkbase xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xmlns:ci=http://www.xbrl.org/sp/general/2005/taxonomia-pgc-2005 xsi:schemaLocation= http://www.xbrl.org/sp/general/2005/pgc-2005 http://www.xbrl.org.es/general/2005/pgc-2005.xsd> <link:schemaRef xlink:type=simp l e xlink:href=http://www.xbrl.org.es/general/2005/pgc-2005.xsd/> <ci:activo precision=3 unitRef=u1 contextRef=c1>727</ci:activo>  <ci:pasivo precision=3 unitRef=u1 contextRef=c1>727</ci:pasivo> <context id=c1></context> <unit id=u1></unit> </xbrl>
15
El elemento XBRL normalmente contendr las definiciones de los espacios de nombres que se utilizarn en el resto del documento. Esto nos evita tener que definir el espacio de nombres muchas veces. El texto xmlns:link=http://www.xbrl.org/2003/linkbase, que aparece como atributo del elemento XBRL, asocia el prefijo link al espacio de nombres http://www.xbrl.org/2003/linkbase de forma que cada vez que usamos link en el resto del fichero nos estamos refiriendo a un elemento definido en el espacio de nombres anterior sin tener que escribir todo el texto. El DTS (Discoverable Taxonomy Set) de este documento lo compone el elemento <link:schemaRef xlink:type=simple xlink:href=http://www.xbrl.org.es/general/2005/pgc-2005.xsd/>
En l podemos ver que slo existe una nica taxonoma referenciada pgc-2005.xsd sin embargo nada nos impide utilizar elementos de muchas taxonomas en un mismo informe siempre y cuando todas ellas estn identificadas mediante los elementos <link:schemaRef> correspondientes. Una taxonoma tambin puede incorporar elementos de otras taxonomas. En este caso la taxonoma que aparece en el DTS del informe es slo la que se encuentre al final de la jerarqua.
p recision=3 significa que los tres caracteres de la izquierda del nmero son significativos a la hora de utilizar el valor 727. Para obtener ms informacin respecto del uso de precision y decimals se debe consultar la especificacin XBRL en el captulo 4.6.3 y siguientes, donde se explica detalladamente y con ejemplos el valor qu se debe interpretar en cada caso.
A continuacin, en el ejemplo anterior tenemos dos elementos de la taxonoma (ci:activo y ci:pasivo) con sus valores correspondientes (727 en los dos casos). Estos elementos contienen la siguiente informacin:
consigue mediante la utilizacin combinada del atributo unitRef y de sucesivos elementos <unit id=u1></unit> en el documento. La sintaxis de definicin de unidades permite definir
del valor 727. En XBRL todos los valores numricos deben tener una unidad de medida. Esto se unidades simples del tipo iso4217:EUR para identificar euros y unidades complejas como m/s2 para definir la aceleracin si esto fuera necesario. El captulo 4.8 de la especificacin XBRL detalla cmo definir unidades simples y complejas en XBRL.
A continuacin nos encontramos con unitRef=u1 que hace referencia a la unidad de medida
El siguiente atributo de los elementos de ejemplo es contextRef=c1. Este atributo permite relacionar el elemento en el que nos encontramos con el contexto dimensional en el que debe ser interpretado. En XBRL los contextos tienen como mnimo dos dimensiones, tiempo y entidad que reporta, sin embargo el contexto es extensible de forma que podemos aadir informacin relativa a la unidad dentro de la organizacin (departamento, persona, etc.) y escenario de interpretacin del informe (estimado, real). Esta informacin se crear utilizando elementos <context id=c1></context> y su sintaxis est descrita en el captulo 4.7 de la especificacin.
16
4.1.2.1Elementos simples y complejos: Items y tuplas
En el ejemplo anterior se estn utilizando dos elementos de la taxonoma: ci:activo y ci:pasivo. Estos dos elementos, dentro de un determinado contexto tienen por s mismos toda la informacin necesaria para ser utilizados. El valor de estos elementos (el nmero) tiene sentido por s mismo, por tanto podemos decir que son elementos simples. Existen muchos casos a la hora de elaborar informes en los que la informacin debe mantenerse agrupada para que pueda ser utilizada. Pongamos como ejemplo que queremos crear un cuadro de directivos de la empresa con el Nombre, Cargo, Salario Fijo y Salario Variable. Para representar esta estructura de datos compleja surge en XBRL lo que denominamos tupla.
La tupla es una estructura de datos que agrupa elementos simples que no proporcionan informacin si se encuentran dispersos. En el ejemplo anterior, la tupla se podra llamar directivo y dentro de ella existir un elemento Nombre, un elemento Cargo, un elemento Salario Fijo y otro para el Salario Variable. Ejemplo 4: TUPLA EN UN INFORME XBRL En un informe XBRL los datos se veran ms o menos as:
<ci:directivo> <ci:nombre contextRef=c1>Juan Ramn Martnez</ci:nombre> <ci:cargo contextRef=c1>Director Financiero</ci:cargo> <ci:salarioFijo unitRef=Euro contextRe f = c 1 precision=INF>45000</ci:salarioFijo> <ci:salarioVariable unitRef=Euro contextRe f = c 1 precision=INF>15000</ci:salarioVariable> </ci:directivo> <ci:directivo> <ci:nombre contextRef=c1>Jos Fernandez</ci:nombre> <ci:cargo contextRef=c1>Director General<ci:cargo> <ci:salarioFijo unitRef=Euro contextRe f = c 1 precision=INF>55000</ci:salarioFijo> <ci:salarioVariable unitRef=Euro contextRe f = c 1 precision=INF>20000</ci:salarioVariable> </ci:directivo>
17
4.1.2.2
Notas aclaratorias en XBRL
Una de las caractersticas ms significativas de los informes XBRL es la posibilidad de incorporar notas a los elementos que aparecen en los informes. En la vida real las notas aparecen en prcticamente todos los informes financieros corporativos y a menudo contienen informacin muy valiosa y que no debe ser ignorada. XBRL incorpora la posibilidad de que los informes incorporen las notas utilizando para ello la potencia de XLink. Ejemplo 5: NOTA AL PIE DEL ELEMENTO CUENTASACOBRAR
<ci:cuentasACobrar id=item1 unitRef=Euro contextRef=c1 precision=INF>455680</ ci:cuentasACobrar>
<link:footnoteLink xlink:type=extended xlink:title=Nota s xlink:role=http://www.xbrl.org/2003/role/link> <link:footnote xlink:type=resourc e xlink:label=footnote 1 xlink:role=http://www.xbrl.org/2003/role/footnote xml:lang=sp>Cuotas, eventos y cursos por cobrar (del ejercicio).Variacin producto del traspaso de los saldos de 2004 a ejercicios anteriores, de la provisin por cuotas no pagadas en el plazo establecido por algunos miembros de la XXXX as como eventos realizados pendientes de pago. <link:footnote> <link:loc xlink:type=locator xlink:label=fact1 xlink:href=#item1/> <link:footnoteArc xlink:type=arc xlink:from=fact1 xlink:to = footnote 1 xlink:title=ver nota aclaratori a xlink:arcrole=http://www.xbrl.org/2003/arcrole/fact-footnote / > </link:footnoteLink>
En el ejemplo vemos cmo el elemento cuentasACobrar tiene un identificador id=item1 el cual es utilizado en el localizador <link:loc /> para referenciar el elemento al que pertenece la nota. El texto de la nota se introduce como un recurso y la relacin entre el elemento y el texto de la nota se define en el arco footnoteArc. 18
Se pueden crear notas en muchos idiomas de forma que el usuario pueda acceder a la informacin que entiende. En el caso anterior bastara con crear un elemento <link:footnote xlink:type=resourc e xlink:label=footnote 1 xlink:role=http://www.xbrl.org/2003/role/footnote xml:lang=en>Payments - Variation of the amount including excluding <link:footnote> Se puede consultar ms informacin respecto de las notas en el captulo 4.11 del documento de la especificacin. Dentro del elemento <link:footnote> anterior.
19
4.1.3 Taxonomas XBRL

Segn la teora de la comunicacin, para que se pueda intercambiar un mensaje entre un emisor y un receptor, debe existir un cdigo que sea conocido por los participantes. Este es el papel de las taxonomas XBRL. Esquema: El conjunto de elementos que pueden aparecer en los informes y la estructura de los mismos. Este conjunto lo denominaremos el diccionario de trminos definidos. - Linkbase de etiquetas: Las etiquetas o textos asociados a los elementos del diccionario que pueden utilizarse en distintos idiomas y con distintos propsitos a la hora de construir representaciones de los informes. - Linkbase de referencias: Las referencias a textos legales o normativas que fundamentan la base de referencias: legal del concepto a modelar. Estas referencias juegan un papel muy importante a la hora de aclarar la utilizacin de los conceptos cuando se van a crear los informes. - Linkbase de presentacin: Las reglas para construir una representacin del informe que se prede presentacin: tende modelar. - Linkbase de clculo: Las reglas de clculo (sumas y restas) entre elementos de la taxonoma que de clculo: permiten validar los informes XBRL. - Linkbase de definicin: Reglas adicionales que permiten documentar relaciones entre elemende definicin: tos de la taxonoma y que se utilizarn para validar los informes.
-
Una taxonoma contiene:
Toda taxonoma XBRL est basada en un esquema XML. Las reglas y limitaciones de los esquemas XML tambin se aplican a las taxonomas XBRL. Una taxonoma XBRL puede incluir otra taxonoma XBRL. Esta caracterstica de XBRL es fundamental para implementar el modelo de extensibilidad. Una empresa que quiera proporcionar ms informacin en sus informes siempre podr crear una extensin de la taxonoma original en la que incluya los elementos y relaciones que no estn creadas en la taxonoma anterior.
El captulo 5 de la especificacin se dedica por completo a explicar las taxonomas XBRL.
20
4.1.3.1 Definicin de conceptos en las taxonomas XBRL

Los conceptos se definen en las taxonomas creando elementos que tengan un tipo de datos definido en los esquemas de XBRL y que pertenezcan al grupo de elementos de item o tupla. Ejemplo 6: DEFINICIN DE UN ELEMENTO EN UNA TAXONOMA XBRL
<element id=tax_CajaYBancos name=CajaYBancos xbrli:periodType=insta n t type=xbrli:monetaryItemType substitutionGroup=xbrli:item nillable=true/>
En el ejemplo tenemos la definicin en el esquema de un concepto simple de la taxonoma llamado CajaYBancos. A continuacin mostramos cmo este elemento se utilizar en un informe XBRL.
<tax:CajaYBancos unitRef=u1 contextRef=c1 precision=7>1523554</tax:CajaYBancos>
Los conceptos de tipo instant son vlidos en un momento concreto del tiempo. Los conceptos de un balance de situacin por ejemplo son de tipo instant.
Todos los elementos que se definan en taxonomas XBRL deben tener un atributo xbrli:periodType=instant o duration lo cual permitir identificar la relacin que el concepto tiene con la coordenada tiempo.
En XBRL hay algunos atributos adicionales que se pueden definir para algunos conceptos. Es el caso del atributo balance=credit o debit que se puede utilizar para identificar si un elemento aparece en la parte izquierda o derecha. En el captulo 4.9 de la especificacin XBRL tenemos documentacin y ejemplos de cmo crear
El valor normal que debemos asumir a la hora de realizar taxonomas es que los conceptos son de tipo duration a no ser que exista una razn para que sean de tipo instant.
Los conceptos de tipo duration tienen un rango de fechas (fecha de comienzo y fecha de finalizacin) para los cuales el dato es vlido. Los datos de una cuenta de resultados hacen siempre referencia a conceptos de tipo duration.
21
Se pueden definir en una taxonoma conceptos abstractos, los cuales no se pueden utilizar en los informes, pero aaden claridad a la hora de mostrar la estructura de la taxonoma. Por ejemplo, el concepto Balance de Situacin no es ningn elemento que contenga datos por s mismo. Sin embargo, en la linkbase de presentacin podremos hacer que este elemento sea el padre del Activo y del Pasivo, y as mantener la taxonoma organizada de forma cmoda.
una tupla de datos en una taxonoma y cmo introducir datos en un informe XBRL.
22
4.1.3.2 Linkbase de etiquetas

Las taxonomas XBRL mantienen meta-informacin sobre los conceptos definidos en el esquema que ayudan a la hora de documentar los conceptos y tambin a la hora de hacer aplicaciones informticas.
Este es el caso por ejemplo de la linkbase de etiquetas. Todas las linkbases se implementan en ficheros separados del esquema de la taxonoma, las relaciones entre la informacin de la linkbase y los conceptos de las taxonomas se hacen mediante XLink. La linkbase de etiquetas proporciona los textos que aparecen en la parte izquierda de los datos. Los humanos interpretamos fcilmente que el dato corresponde al concepto que aparece en la misma fila. Si en un informe aparece por ejemplo: Caja y Bancos . . . . . . . . . . . . . . . . . . . . . . . . . . 1000
El texto Caja y Bancos aparecer en XBRL en la linkbase de etiquetas, de esta forma podremos tener textos en mltiples idiomas y textos distintos para adaptarnos a los dispositivos en los que se tenga que formatear la informacin.
Una persona identificar el concepto mediante el texto de la izquierda, y el valor en la columna de la derecha.
definir las etiquetas que un concepto tendr de acuerdo con lo distintos roles. Un ejemplo de utilizacin de roles puede ser el texto asociado al concepto resultado de explotacin. Si es positivo ser Beneficio de explotacin si es negativo ser Prdidas de explotacin. El captulo 5.2.2 de la especificacin proporciona ms informacin respecto de la utilizacin de la linkbase de etiquetas.
Las etiquetas tienen un rol asociado. Es posible definir roles propios de una taxonoma y luego
23
4.1.3.3 Linkbase de referencias

Una de las linkbases ms importantes en la definicin de una taxonoma de uso pblico es la linkbase de referencias. Esta linkbase proporciona informacin respecto de los textos legales en los que podemos encontrar informacin adicional sobre el concepto. Esta linkbase ser de mucha utilidad a la hora de localizar los conceptos que deben usarse para elaborar informes XBRL que utilicen la taxonoma del IFRS por ejemplo. El procedimiento ms sencillo para elegir un concepto de la taxonoma sera el siguiente:
1 Partiendo del concepto que aparece en el documento contable localizaremos las referencias en el IFRS mediante la documentacin proporcionada por los auditores de la empresa o el libro de cuentas corporativo. Esta informacin ser por ejemplo IAS-20 lo cual significa que el concepto utilizado en el informe se encuentra documentado en el libro de normativa internacional de contabilidad IAS, prrafo 20. 2 El siguiente paso sera buscar en la linkbase de referencias usando IAS-20 qu conceptos estn referenciados.
una empresa y la normativa internacional de contabilidad.
Este procedimiento sencillo permitir crear un mapa entre los conceptos contables utilizados en
El captulo 5.2.3 de la especificacin XBRL define la sintaxis a utilizar en las taxonomas para documentar los elementos que definen las relaciones con los textos legales. Las taxonomas son muy flexibles a la hora de crear nuevos conceptos que se puedan utilizar para este propsito.
24
4.1.3.4 Linkbase de presentacin

Esta linkbase tiene un doble propsito: por un lado sirve para que las herramientas de creacin o visualizacin de taxonomas nos muestren el contenido de la misma de forma ms amigable que una simple lista de conceptos. Por otro lado sirven de base para que las aplicaciones que formatean los informes de forma automtica tengan un punto de partida por el que empezar a construir las plantillas que mostrarn los datos. La linkbase de presentacin tiene una estructura jerrquica. Se construye relacionando los elementos hijos con los elementos padre usando XLink.
Existe un atributo opcional llamado preferredLabel que aplica al arco XLink que une dos elementos en una linkbase de presentacin. Este atributo puede contener el valor del rol que el elemento juega en ese momento especfico. Es muy habitual que a la hora de modelar algunos apartados de la memoria nos encontremos con: Movimientos en las Reservas: Reservas al inicio del ejercicio . . . . . . . . . . . . . .10000 Incrementos o disminuciones de las reservas . . . .2500 Reservas al final del ejercicio . . . . . . . . . . . . . .12500
El captulo 5.2.4 de la especificacin XBRL proporciona ms informacin sobre la utilizacin de esta linkbase.
Existen tres conceptos en la taxonoma. Uno denominado Reservas, otro denominado Incrementos o disminuciones de las reservas y un concepto abstracto denominado Movimientos en las Reservas El concepto Reservas tiene tres etiquetas: Reservas para el rol etiqueta normal (se utilizar en el balance por ejemplo). Reservas al inicio del ejercicio para el rol inicio del ejercicio. Reservas al final del ejercicio para el rol final del ejercicio.
En XBRL esto se debe modelar de la siguiente manera:
El concepto Reservas ser de tipo instant.
En la misma linkbase de presentacin, aparecer el elemento Incrementos o disminuciones de las reservas como segundo hijo del elemento abstracto Movimientos en las reservas.
El concepto Movimientos en las Reservas es de tipo abstracto, por lo que no es significativo que sea instant o duration. En la linkbase de presentacin, dentro de algn apartado de la memoria figurar que el concepto Reservas es el primer hijo del elemento abstracto Movimientos en las reservas, y que el preferredLabel es inicio del ejercicio.
El concepto Incrementos o disminuciones de las reservas ser de tipo duration.
Por ltimo, aparecer otra vez el elemento Reservas como tercer hijo del elemento abstracto Movimientos en las reservas pero en esta ocasin la preferredLabel ser final del ejercicio. 25
4.1.3.5 Linkbase de clculo
Esta linkbase permite crear relaciones entre elementos similares a las de la linkbase de presentacin. En esta ocasin, los elementos padre sern el resultado de las operaciones aritmticas que se deban realizar con los elementos hijos. Estas operaciones slo podrn ser sumas o restas de los elementos hijos. La especificacin define en el captulo 5.2.5 la forma de definir estas redes de clculo.
Los documentos XBRL se pueden validar con respecto a estas redes de clculo. Los documentos XBRL que presenten errores en los clculos no sern vlidos desde el punto de vista de XBRL. Las aplicaciones informticas podrn tener en cuenta estos errores de clculo para admitir o rechazar automticamente los documentos entrantes.
4.1.3.6 Linkbase de definicin

La ltima de las linkbases definidas en la especificacin XBRL 2.1 es la linkbase de definicin. El contenido de esta linkbase es establecer relaciones entre los elementos de una taxonoma que permitan explicar o documentar relaciones, as como aadir ciertas reglas que pueden ser importantes a la hora de validar documentos XBRL. Las relaciones entre elementos definidas en la especificacin son 4: general-special: Define relaciones de lo general a lo especfico. El ejemplo que aparece en la especificacin es que zipCode es una especializacin de postalCode. e s sence-alias: Este arco se suele utilizar a la hora de relacionar conceptos de diferentes taxonomas o dos conceptos en la misma taxonoma para indicar que ambos son esencialmente el mismo. similar-tuples: se utiliza de forma similar al essence-alias pero para las tuplas. Existen diferencias con respecto al arco essence-alias que vienen documentadas en la especificacin. requires-element: Este arco se utiliza para obligar a que exista un elemento en un informe en el caso de que exista otro elemento.
Las linkbases son tambin extensibles. Nada en la especificacin impide que se desarrollen linkbases propietarias para relacionar modelos de datos internos con elementos de taxonomas si bien esas linkbases debern ser privadas dado que no existe una especificacin aprobada en el consorcio para que todos los procesadores XBRL las entiendan.
4.1.4 Referencias
Especificacin XBRL 2.1:
XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2005-03-24.doc
26
4.2 Almacenamiento
4.2.1 Almacenamiento XML/XBRL

La aparicin de nuevas tecnologas suele aportar soluciones a problemas existentes y abrir nuevas posibilidades de desarrollo, pero tambin suele traer consigo nuevos requerimientos.
La implantacin de lo que podramos llamar tecnologa XML ha resuelto determinados problemas sobre todo en el mbito de las comunicaciones entre plataformas diversas, pero tambin ha trado consigo requerimientos, tales como el almacenamiento de los documentos y el acceso a sus contenidos, estructurados de manera distinta a la informacin generalmente hasta ahora tratada. XBRL surge como una versin potente y flexible del XML, definida especficamente para satisfacer las exigencias de la informacin financiera y empresarial. Si bien XBRL desde un punto de vista funcional plantea una especializacin con respecto a XML, desde un punto de vista tecnolgico no plantea ningn cambio estructura l que impida que la mayor parte de las herramientas y plataformas de gestin, administracin y explotacin de contenidos diseadas
para XML no puedan ser utilizadas con XBRL.
Este documento pretende identificar los requerimientos de los contenidos XBRL y las tcnicas actuales que plantean soluciones a esos requerimientos, desde el punto de vista de su almacenamiento, gestin y explotacin. Para ello, se analizan los distintos mtodos de almacenaje, se identifican los principales productos que existen en el mercado que implementan dichos mtodos y se describen las herramientas destinadas a la administracin, gestin y explotacin de los contenidos XBRL.
27
4.2.1.1
Los documentos o instancias XBRL se estructuran y articulan normalmente en ficheros de texto plano. Sobre esta base, la primera opcin a plantearse sera almacenar los contenidos XBRL en su envase habitual, es decir, el propio fichero. - El documento no es tratado y por tanto su contenido (informacin) no se ve sometido a ninguna alteracin o distorsin. - Facilidad para gestionar los documentos a nivel de archivo, siempre que se articule una estructura de ficheros adecuada que permita clasificarlos atendiendo a los criterios establecidos por la propia organizacin. - Se presentan los problemas tpicos asociados a la gestin de ficheros: falta de concurrencia, comprobacin de integridad, seguridad... Partiendo del supuesto de que los contenidos XBRL son almacenados para su posterior consulta, publicacin o explotacin por parte de otros sistemas, se hace necesario contar con herramientas que permitan acceder, localizar y extraer informacin. En el caso de un almacenamiento en ficheros, algunas de las herramientas disponibles son las siguientes:
Almacenamiento en ficheros
Ventajas: Ventajas:
Desventajas: Desventajas:
Productos / Herramientas: Productos / Herramientas:
implementan motores de bsqueda basados en Xquery sobre archivos XML/XBRL. XQJ: - XQJ: es el API de Xquery para Java. Lo que es JDBC para SQL, lo es XQJ para Xquery. Es una manera de estandarizar el acceso y que cada producto no tenga que tener su propio API. Est siendo desarrollado por la Java Community Process (JCP especificacin 225), los detalles de su desarrollo se pueden ver en http://jcp.org/en/jsr/detail?id=225. Actualmente se encuentra disponible la versin 2.3 que puede ser descargada desde esta pgina.
- Desde aplicaciones desarrolladas en Java, C++... se pueden invocar motores de bsqueda XML/XBRL partiendo de libreras (APIs) ya desarrolladas y disponibles en el mercado que
- Motores de bsqueda para ficheros XML/XBRL cuya sintaxis de consulta se basa en Xquery. La mayor parte de estos motores de bsqueda proporcionan un API que permite el acceso y uso del motor desde aplicaciones externas (normalmente Java o C++). XQEngine - XQEngine (http://xqengine.sourceforge.net).
28
Microsoft.Xml.Xquery.dll: - Microsoft.Xml.Xquery.dll: librera de Microsoft para implementar consultas en archivos usando Xquery. - Existen tambin entornos de desarrollo que integran edicin y bsquedas Xquery y Xpath proporcionando adems un API que integra XQJ. DataDirect Xquery - DataDirect Xquery (http://www.stylusstudio.com).
29
4.2.1.2
Muchas empresas que se planteen la disyuntiva del almacenamiento de los documentos XBRL, optarn por la reutilizacin de los sistemas de almacenamiento ya existentes en su organizacin. En este caso lo ms habitual sern las Bases de Datos relacionales. La pregunta a plantearse en ese momento ser: Cmo almaceno contenidos XBRL en una Base de Datos relacional? La respuesta pasa por una serie de opciones: - Transformando los contenidos XBRL al modelo relacional. - Almacenando los contenidos ntegros en columnas de un tipo especfico. Ventajas: - Las Bases de Datos relacionales son productos muy robustos y que podran considerarse maduros teniendo en cuenta su evolucin e implantacin en el mercado. - La gran mayora de las aplicaciones actuales que acceden, consultan, gestionan, analizan, y publican contenidos, se encuentran cimentadas entorno a sistemas de Bases de Datos relacionales, por lo que acomodar la informacin XBRL a estos sistemas trae consigo la posibilidad de reutilizar estas aplicaciones. Desventajas: - La conversin y transformacin de los datos XBRL a un modelo relacional exige una manipulacin, en mayor o menor medida, de la informacin. Esta manipulacin conlleva en determinados casos que no se pueda garantizar la integridad, ni asegurar que lo que se mues- Si el documento XBRL no ha sido generado a partir de un esquema relacional, la adecuacin posterior a un modelo relacional no resulta sencilla sobretodo en la conversin de determinados elementos: - Elementos anidados. - Elementos que se repiten (atributos multivaluados). tra o recupera sea exactamente lo mismo que el documento original recibido en XBRL.
Desventajas: Ventajas:
Almacenamiento en Bases de Datos Relacionales
30
4.2.1.2.1 Transformacin de contenidos XBRL a modelos relacionales

El proceso de transformacin conlleva la fragmentacin del contenido del documento, es decir, los datos que contiene el archivo XBRL son extrados y almacenados en entidades de la Base de Datos. Para empezar, conviene aclarar que utilizando este mtodo de almacenamiento no se guarda informacin en formato XBRL como tal en la Base de Datos, el documento XBRL es completamente ajeno a la BBDD y una vez es utilizado para extraer la informacin es descartado. El hecho de recuperar un documento significa consultar a la BBDD y construir un documento XBRL con los resultados obtenidos.
Una consecuencia importante de utilizar este sistema es que existe informacin referente al documento XBRL que no llega a almacenarse en la BBDD y se pierde, como puede ser el orden en que aparecen los elementos en el documento.
El modelo relacional ser eficiente en la medida que los datos sean altamente estructurados y tengan un esquema conocido. Este modelo aportar la ventaja de que permite hacer consultas de la manera tradicional, aunque stas debido a la estructura del XML requerirn, a menudo, una gran cantidad de joins. repiten, ya que su uso obliga a usar representaciones en rbol o a almacenar la relacin entre elementos de nivel superior e inferior.
Sin embargo, esta opcin no es la mejor si existen elementos anidados o elementos que se
La manera ms sencilla de usar este tipo de almacenamiento es definir un mapeo entre los datos del archivo XML y las tablas de la Base de Datos. De esta manera se pueden cargar datos de manera masiva. Tambin este mapeo se utilizara para el proceso inverso, es decir tenemos datos en tablas y queremos generar el XML a partir de ellos. SQL Server 2005 - SQL Server 2005 (http://www.microsoft.com).
Proporciona una herramienta destinada al mapeo entre almacenamiento XML/XBRL y relacional. Esta herramienta es conocida como Annotated XML (AXSD). AXSD permite descomponer un documento XML/XBRL en columnas de una o ms tablas, preservando la fidelidad de los datos a nivel relacional -se preserva la estructura jerrquica, mientras que se ignora el orden entre los elementos-. El esquema no puede ser recursivo.
31
Al definir un mapeo entre los esquemas XML y las tablas en la Base de Datos, se crea una vista XML de los datos persistentes. La carga de XML puede ser utilizada para poblar las tablas subyacentes utilizando la vista XML. Se puede consultar la vista XML utilizando Xpath 1.0, la consulta es traducida a las consultas SQL en las tablas. De manera similar, las actualizaciones se propagan a esas tablas. Esta tecnologa es til cuando: - Se desea tener un modelo de programacin centrado en XML utilizando vistas XML sobre sus datos relacionales existentes. - Tiene un esquema (XSD, XDR) para sus datos XML, el cual puede haber sido provisto por un socio de negocios externo. - El orden no es importante en sus datos, o sus datos disponibles para consultas no son recursivos, o la profundidad mxima de recursividad se conoce con antelacin. - Desea consultar y modificar los datos mediante la vista XML utilizando Xpath 1.0. - Desea cargar datos XML y descomponerlos en las tablas subyacentes utilizando la vista XML.
D - DB2 XML Extender (http://www.ibm.com). IBM incorpora a su DB2-UDB a partir de la versin 7.0, un nuevo mdulo denominado DB2 XML Extender. Se trata de una herramienta destinada a la integracin de XML y DB2, que permite almacenar documentos XML en Bases de Datos atendiendo a un mtodo deno-minado: M todo XML Collections. Mtodo XML Collections: Mtodo XML Collections: Este mtodo permite mapear la estructura de un documento XML a tablas de DB2. De esta forma se pueden generar documentos a partir de datos almacenados en la BBDD, y viceversa, fragmentar documentos XML y guardarlos en la BBDD. Una XML Collection est formada por un conjunto de entidades de la BBDD que han sido mapeadas contra un documento XML por medio de un documento de tipo DAD (Data Access Definition). Este tipo de fichero, generado en XML, es el que permite al XML Extender construir sentencias de tipo INSERT y SELECT que permitan publicar XML o fragmentarlo en la BBDD. Digamos que posibilita un mapeo bidireccional. Para publicar datos XML usando XML Extender, se ha de llamar a una serie de procedimientos almacenados de Base de Datos creados para tal efecto. IBM recomienda el uso de las XML Collections en los siguientes casos: - Si se poseen datos previamente en la BDD y a partir de ellos se pretende generar documentos en XML. - Si se poseen documentos XML cuya estructura posibilita un mapeo ptimo con entidades de la Base de Datos.
32
Oracle XML DB es la Base de Datos Oracle 9i con soporte para XML, concebida para la gestin de contenidos XML y el desarrollo de aplicaciones basadas en dicho formato
O - Oracle XML DB (http://www.oracle.com)
- Si lo que interesa almacenar de los documentos XML son tan slo sus datos dejando a un lado sus tags. - Si se prevn actualizaciones frecuentes de partes de esos documentos. - Si los documentos exceden de 2 gigabytes de tamao.
Los elementos del esquema XML se mapean como objetos en los que cada elemento anidado de tipo simple es representado por un atributo de un tipo nativo lo ms acorde posible con el tipo del esquema: si es un nmero con NUMBER, si es texto con VARCHAR...
Esta BBDD implementa un tipo de datos especfico para XML (XMLType) que, entre otras cosas, posibilita la fragmentacin en estructuras relacionales de contenidos XML para un mejor aprovechamiento de las capacidades SQL. Para ello, el tipo XML se asocia a un esquema que defina su estructura.
El XMLType tiene toda una serie de mtodos ya definidos para crear, extraer, indexar, etc., informacin XML almacenada en la BD, que estn disponibles a travs de las APIs para PL/SQL y Java. Entre las caractersticas ms destacables de este producto: - Se preserva el estndar DOM a la hora de fragmentar y almacenar documentos. Esto quiere decir que el proceso de almacenamiento no afecta al orden de los elementos, la presencia de namespaces, etc., salvo los espacios en blanco. - Da la posibilidad de crear tablas y tipos a travs de un esquema XML dado, forzando a que un documento XML que se pretende almacenar sea vlido para ese esquema. - Permite actualizaciones parciales de informacin mediante el uso de Xpath. - Posibilita el uso de la sintaxis del Xpath mediante SQL embebido para poder consultar contenido XML residente en la BDD. - Con Xpath se pueden indexar partes de un documento para optimizar bsquedas. - Permite la creacin de vistas XML para crear estructuras permanentes de informacin a travs de fragmentos de varios documentos XML o de objetos relacionales de la Base de Datos, mostrndolos como documentos XML. - Incorpora un repositorio donde poder ver el contenido XML almacenado a travs de una estructura jerrquica de directorios, de manera opuesta al mtodo tradicional de las Bases de Datos relacionales, donde cada directorio es un nodo en la jerarqua que contiene un conjunto de recursos.
33
4.2.1.2.2 Almacenamiento de documentos ntegros en columnas de tipo XML

Una solucin para el almacenamiento de XML/XBRL es el empleo de las columnas de tipo XML que los distintos fabricantes de software (Bases de Datos) han incluido en sus productos.
Tambin se debe tener en cuenta que al tratarse de contenidos basados en texto plano, siempre existe la posibilidad de guardar el XML en un campo de tipo VARCHAR, con el inconveniente de que esto es til slo si se opta por almacenar y recuperar el texto ntegro sin necesidad de bsquedas interiores. No obstante, en este caso se debe tener en cuenta que: - Se puede combinar con las columnas de tipo XML para mantener una copia exacta (aunque exista redundancia), por ejemplo para documentos legales. - Se puede convertir en tipo XML en tiempo de ejecucin para ejecutar Xquery por ejemplo, aunque penalizara bastante el rendimiento.
Lo ms habitual ser no utilizar el tipo VARCHAR sino el tipo de datos XML. Este uso ser aconsejable cuando: - No se conoce la estructura de los datos, o la estructura de sus datos puede cambiar significativamente en el futuro. - Los datos representan jerarqua de contencin (de manera opuesta a las referencias entre entidades) y muchos son recursivos. - El orden es inherente en sus datos. - Se necesita que los datos sean validados por el motor de la BBDD contra un esquema, un DTD o una taxonoma.
Un tipo de datos XML permite que los datos sean indexados, que puedan ser consultados o modificados por medio de Xquery y XML DML (extensin para la modificacin de datos).
Resumiendo, el almacenamiento en columnas de tipo XML es til cuando tiene documentos XML con una variedad amplia de estructuras, o documentos XML conformes con esquemas complejos o diferentes que son muy difciles de mapear con estructuras relacionales.
Los datos son almacenados en una representacin interna que preserva el contenido XML de los datos, como por ejemplo la jerarqua de contencin, orden del documento, valores de elementos y atributos, y as sucesivamente. De manera especfica, se preserva el contenido InfoSet de los datos XML (para ms informacin acerca de InfoSet, visite http://www.w3.org/TR/xml-infoset). 34
- SQL Server 2005 - SQL Server 2005 (http://www.microsoft.com).
Puede no ser una copia exacta del texto XML, ya que la siguiente informacin no es retenida: espacios en blanco insignificantes, orden de atributos, prefijos de nombres, y declaraciones XML. Una columna de tipo de dato XML puede ser creada en una tabla conteniendo columnas relacionales, o en una tabla separada con una relacin de clave externa a una tabla principal. Se aconseja que se cree una columna de tipo de dato XML en la misma tabla cuando se cumple una de las siguientes condiciones:
Se aconseja crear una columna de tipo de dato XML en una tabla separada si se da alguna de las siguientes condiciones:
- La aplicacin realiza extraccin de datos en una columna XML y no requiere un ndice XML en la columna XML. - Se desea construir un ndice XML en una columna de tipo de dato XML, y la clave principal de la tabla principal es la misma que la clave de clustering.
Las columnas de tipo de datos XML, variables y parmetros pueden ser tipados utilizando esquema XML pero no utilizando DTD.
ta con una clave primaria, o la tabla principal no cuenta con clave de clustering. Esto puede ser verdadero si la tabla principal ya existe. - No se desea que el escaseado de tabla disminuya debido a la presencia de la columna XML en la tabla, lo cual ocupa espacio si se encuentra almacenado en la fila o fuera de la fila.
- Se desea construir un ndice XML en la columna de tipo de dato XML, pero la clave primaria de la tabla principal no es la misma que la clave de clustering, o la tabla principal no cuen-
to de la consulta. Sus aplicaciones pueden beneficiarse de un ndice XML bajo las siguientes condiciones: - Las consultas en columnas XML son comunes en su carga de trabajo. Debe ser tenido en cuenta el costo de mantenimiento de ndices XML durante la modificacin de datos. - Sus valores XML son relativamente grandes y las partes recuperadas son relativamente pequeas. Construir el ndice evita analizar los datos durante runtime, y beneficia la bsqueda por ndices para el procesamiento efectivo de consultas.
Los ndices XML pueden ser creados en una columna de tipo de datos XML. Los mismos indexan todas las etiquetas, valores y paths sobre las instancias XML en la columna, y beneficia el rendimien-
SQLServer implementa dos tipos de datos XML denominados XML sin tipo y XML con tipo. La diferencia ms importante entre ambos tipos se sustenta en la validacin o no de los datos XML contra un esquema dado. Microsoft recomienda el uso de XML sin tipo bajo las siguientes condiciones: - No se cuenta con un esquema para sus datos XML.
35
- Se cuenta con esquemas pero no desea que el servidor valide los datos. Este suele ser el caso cuando una aplicacin realiza validacin del lado del cliente antes de almacenar los datos al servidor, o almacena de manera temporal datos XML invlidos de acuerdo con el esquema, o utiliza componentes de esquema no soportados por el servidor (por ejemplo, key/kevref). Microsoft recomienda el uso de XML con tipo bajo las siguientes condiciones: - Se cuenta con esquemas para los datos XML y desea que el servidor valide sus datos XML de acuerdo a sus esquemas XML. - Se quieren aprovechar las mejoras de almacenamiento y consultas inherentes a este tipo de datos. - DB2 XML Extender (http://www.ibm.com). D
-
- Se quieren aprovechar las mejoras implementadas para este tipo de datos en lo referente a la compilacin de las consultas. Esta herramienta de DB2-UDB implementa un mtodo denominado XML Columns que permite almacenar documentos XML de manera ntegra en DB2. Los documentos se insertan en columnas de un tipo XML sobre las que se pueden realizar bsquedas, actualizaciones... XML Extender diferencia entre varios tipos de datos que pueden albergar contenidos XML: - XMLVARCHAR (almacena documentos de 3 K como tamao mximo).
Todos los documentos que se almacenen en una determinada columna de tipo XML deben ajustarse a un mismo esquema XML.
- XMLCLOB (permite almacenar documentos de hasta 2 GB de tamao). - XMLFILE (almacena el nombre del fichero, no su contenido, permaneciendo el documento en el file system. Vlido para documentos almacenados fuera de la BBDD).
A tener en cuenta que los espacios en blanco son respetados, algo importante para el XML, as como el orden de los elementos, comentarios, etc.
La indexacin de este tipo de datos se puede llevar a cabo mediante el uso de lo que se conoce como side tables, que son una especie tablas satlite que almacenan partes concretas del documento (elementos y atributos) que sern consultados con frecuencia. Contiene una clave fornea que apunta a la tabla y columna que contiene el documento en formato ntegro. Esto permite agilizar tanto las consultas sobre determinados valores como las que recuperan todo el documento. A su vez, cuando el documento almacenado en la columna XML es actualizado, los valores de estas tablas auxiliares tambin lo sern automtiicamente. dos en este tipo de tablas se debe crear un fichero tipo DAD, que a su vez es otro archivo XML, aunque con una estructura diferente al utilizado por las XML Collections.
Para especificar qu valores del documento son los que tienen que ser extrados y almacena-
36
El uso de estas tablas es la manera ms rpida para recuperar la informacin almacenada en una columna XML y por tanto se aconseja su utilizacin. XML Extender proporciona toda una serie de funciones definidas que permiten: - Importacin de documentos del file system a la BBDD. - Realizacin de bsquedas. - Lanzar actualizaciones. - Exportacin de datos de la BBDD al file system.
Este tipo de almacenamiento permite albergar intactos los documentos XML/XBRL, preservando su integridad, siendo especialmente eficaz cuando los datos de los documentos son consultados con asiduidad y raramente actualizados. Este sistema se muestra tambin especialmente eficaz en el caso de que se trabaje sobre documentos de gran extensin y se pretenda realizar bsquedas a la vez que se quiera preservar la integridad de los mismos intacta.
Este sistema permite almacenar el documento de manera externa a la BBDD (en un sistema de ficheros), bien sea local o remoto, y usar DB2 para las operaciones de mantenimiento y consulta A partir de un nuevo tipo de datos especfico para XML (XMLType) esta BBDD permite almacenar contenidos XML en una columna de una tabla a travs de un objeto CLOB que representa al documento como una instancia. Entre las caractersticas ms destacadas, cabe sealar: - Proporciona mtodos que permiten operaciones comunes como validaciones de esquemas. - Puede ser usado como cualquier otro tipo de dato en una tabla relacional. - El tipo XMLType proporciona constructores que permiten que sea creado a partir de un tipo VARCHAR o CLOB, y proporciona un nmero de mtodos especficos XML para operar con los objetos XMLType. - Se preserva el estndar DOM a la hora de fragmentar y almacenar documentos. Adems se conservan los espacios en blanco. - Oracle XML DB (http://www.oracle.com).
- Oracle XML DB
37
4.2.1.3
Introduccin y Antecedentes:
Almacenamiento en Bases de Datos XML Nativas
Como se ha visto en los apartados anteriores, las BBDD Relacionales suponen una posibilidad para el almacenamiento de datos XML, sin embargo, no estn diseadas especficamente para almacenar estructuras de tipo jerrquico como son los documentos XML:
Una alternativa a los Sistemas Relacionales son los Sistemas de Bases de Datos Orientados a Objetos (SGBDOO). Los SGBDOO soportan un modelo de objetos puro, en la medida en que no estn basados en extensiones de otros modelos ms clsicos como el relacional. Estos sistemas ofrecen caractersticas que los hacen especialmente interesantes de cara al almacenamiento de informacin XML:
- Las BBDD relacionales tienen una estructura regular frente al carcter heterogneo de los documentos XML. - Los documentos XML suelen contener muchos niveles de anidamiento mientras que los datos relacionales son planos. - Los documentos XML tienen un orden intrnseco mientras que los datos relacionales son no ordenados. - Los datos relacionales son generalmente densos (cada columna tiene un valor) mientras que los datos XML son dispersos, pueden representar la carencia de informacin mediante la ausencia del elemento.
- Considera toda la informacin del documento como objetos de clases predefinidas interconectadas mediante enlaces que preservan la estructura del documento XML. - Emplean la aproximacin DOM y permite tratar documentos que estn bien formados. - La opcin de una SGBDOO es empleada por varias Bases de Datos Nativas, pero los pio SGBDOO, y por lo general, no son especficos para el modelo XML. mecanismos de indexacin, optimizacin, procesamiento de consultas, etc. son las del pro-
La organizacin XML:DB Initiative for XML Databases (http://www.xmldb.org) describe una Base de Datos XML Nativa como un modelo lgico para documentos XML que almacena y recupera documentos de acuerdo a dicho modelo. 38
BBDD XML Nativas:
Poet (http://www.poet.com) Jasmine (http://www.cai.com) ObjectStore (http://www.odi.com) GemStone (http://www.gemstone.com)
Como ejemplos de SGBDOO existentes en el mercado:
A diferencia de las Bases de Datos relacionales cuya operatividad gira alrededor de los d a tos atmicos, las Base de Datos Nativas en XML carecen de campos, no centrndose en el almacenamiento de datos atmicos sino en el de documentos (XML).
que podramos catalogar de tipo XML como son DOM o Infoset. En estos repositorios se almacenan tambin los ndices generados y asociados a cada documento XML. Algunas de las caractersticas que distinguen a las BBDD XML Nativas son: - Emplear como unidad lgica de almacenamiento el documento XML. - Preservar el orden del documento, las instrucciones de procesamiento, los comentarios, las secciones CDATA y las entidades, es decir, responde a un esquema (DTD, XML Schema). - La mayora de las BBDD XML nativas soportan uno o ms lenguajes de consulta. Uno de los ms populares es Xquery. - Validacin de los documentos. - Almacenamiento de documentos en colecciones. Las colecciones juegan en las Bases de Datos nativas el papel de las tablas en las BBDD relacionales. Los documentos se suelen agrupar, en funcin de la informacin que contienen, en colecciones que a su vez pueden contener otras colecciones. - Indexacin XML. Permiten la creacin de ndices que aceleren las consultas ms habituales. - Creacin de identificadores nicos. A cada documento XML se le asocia un identificador nico por el que ser reconocido dentro del repositorio. - Soportar APIs de programacin (SAX, DOM, JDOM...)
Este tipo de BBDD almacenan informacin en formato XML sirvindose de unos repositorios
- No tienen ningn modelo de almacenamiento fsico subyacente concreto. Como se ha sealado, las BBDD XML Nativas existentes en la actualidad no poseen un mo-delo de almacenamiento fsico subyacente concreto, es decir, son construidas sobre diversas estructuras de BBDD: relacionales, jerrquicas, orientadas a objetos o bien mediante formatos de almacenamiento propietarios. Ventajas: - Se trata de sistemas de almacenamiento diseados especficamente para almacenar contenidos XML, con lo que ello supone: - No es necesaria la conversin de la informacin a estructuras relacionales u otro tipo ajeno a las estructuras propiamente XML. - Implementa herramientas de gestin y consulta de contenidos expresamente diseadas para este tipo de informacin, con los consiguientes beneficios en lo que respecta a su operatividad, eficacia y rendimiento. - Implementan herramientas especficas para este tipo de informacin, como puede ser los mdulos de validacin contra esquemas, DTDs o taxonomas. 39
Ventajas:
- Implementan una indexacin especfica y adecuada a los contenidos XML, por lo que su eficacia en la localizacin, tratamiento y recuperacin de la informacin es mayor.
Atendiendo a la denominacin del fabricante, podramos denominar este producto ms que como una simple Base de Datos XML Nativa, como un servidor de informacin ntegramente XML, capaz de almacenar, gestionar, publicar y servir de plataforma de intercambio de documentos XML. Este servidor de informacin, est basado en estndares abiertos. Entre las pricipales caractersticas de este producto cabe destacar:
- Tamino XML Server - Tamino XML Server (versin 4.2) (http://www.softwareag.com).
- Alto Rendimiento y disponibilidad ya que su motor XML es multi-proceso, permitiendo grandes volmenes de peticiones y usuarios. Admite acceso mediante URL, soportando todos los estndares de acceso Web (HTTP, ISAPI, NSAPI, Apache API). - Multiplataforma. Tamino puede invocarse desde cualquier cliente que tenga una mquina virtu- Soporta Xquery como lenguaje de consulta y adems un lenguaje definido por el propio fabri- Cabe destacar su integracin con BBDD relacionales o Adabas de forma que este servidor de informacin disponibiliza los contenidos de dichas Bases de Datos para aplicaciones basadas en l. - Alta escalabilidad. En lo referente a su arquitectura, el servidor est cimentado en cinco mdulos especializados: cante, basado en Xpath y denominado Tamino X-Query. al Java instalada. Tambin puede invocarse desde componentes basados en ActiveX o C++.
- X-Machine: es el ncleo de alto rendimiento encargado del almacenamiento de objetos XML. X-Machine administra todas las estructuras de datos bien estn en formato XML o SQL, imgenes, archivos de audio, vdeo o datos recuperados a travs de X-Node. - X-Node: implementa el acceso a fuentes de informacin con estructuras de datos tradicionales como BBDD relacionales o Adabas. X-Node proyecta estos datos en estructuras XML. - SQL Engine permite el almacenamiento de datos SQL en Tamino. Esos datos pueden ser bien parte de documentos XML o utilizados por aplicaciones que slo trabajan con datos SQL, pero que se ejecutan en el mismo servidor que Tamino. - X-Manager: permite al administrador de Tamino proyectar todos los objetos XML a estructuras internas y administrar el sistema completo. - Data Map: contiene meta-datos como los DTDs, hojas de estilos, esquemas relacionales, etc. Data Map tambin determina cmo sern proyectados los documentos XML en las estructuras fsicas de datos. 40
Aunque no se trata de un nuevo sistema de almacenamiento, ya que como tal utiliza el producto anteriormente reseado (Tamino XML Server), merece la pena destacarlo en este documento, ya que este suite est pensado y diseado expresamente para el tratamiento, gestin, intercambio y almacenamiento de contenidos XBRL. Este producto surge a partir de una reciente alianza entre Software AG y Semansys Technologies con el objetivo de ofrecer al mercado un paquete (Suite) cerrado y centrado en XBRL. Semansys Tamino XBRL Suite, integra los productos para el procesado, validacin y manipulacin de XBRL de Semansys, apoyndose en la BDD XML nativa, Tamino XML Server. Este producto est constituido por varios mdulos especializados:
- Semansys Tamino XBRL Suite - Semansys Tamino XBRL Suite (http://www.semansys.com http://www.softwareag.com).
- Soporte de mltiples APIs y herramientas de desarrollo de terceros, al poder utilizar J2EE o . N E T . - Soporte de los estndares abiertos propuestos por W3C (HTPP, XML, Xquery, Xpath, XML Schema, Namespaces...), aportando flexibilidad en el diseo y desarrollo de aplicaciones y productos. - Mltiples plataformas soportadas: Windows, Solaris, Linux, Unix System V.
Otras de las caractersticas destacables de este producto son:
Xindice es la continuacin de un proyecto anterior llamado dbXML Core. El cdigo fue donado por el grupo dbXML (http://www.dbxml.com) a Apache Software Foundation en Diciembre de 2001. - Utiliza Xpath como lenguaje de consulta y XML:DB XUpdate como lenguaje de actualizacin en la BBDD. - Proporciona una implementacin de XML:DB API para la invocacin desde desarrollos Java. - Mediante XML-RPC plugin es posible acceder a Xindice desde otros entornos o lenguajes. - Los estndares de XML que soporta Xindice son los recomendados por W3C. - Es un producto muy ventajoso desde el punto de vista econmico ya que se sustenta sobre el tipo de licencia: Apache Software License. 41 Entre las caractersticas ms destacables de este producto:
- Xindice (versin 1.1.b4) - Xindice (versin 1.1.b4) - (http://xml.apache.org).
- Semansys XBRL Composer es utilizado para recopilar la informacin de diferentes fuentes y formatos y transformarlo en XBRL. - Semansys XBRL Integrator es el gestor de datos para usar esa informacin guardada en XBRL. - Semansys XBRL Reader permite acceder a los documentos XBRL as como su manipulacin. - S o ftware AG Tamino es utilizada como BBDD XML Nativa.
Se trata de una versin Open source de una Base de Datos XML Nativa. Entre las caractersticas ms destacables de este producto:
- eXist (versin 1.0.b2) - (http://exist.sourceforge.net/).

- eXist (versin 1.0.b2)
- Soporta Xquery 1.0 como lenguaje de consulta, indexacin y procesado de la informacin. Tambin soporta Xupdate pero de una forma limitada. - Implementa un API para la invocacin desde aplicaciones Java. - Implementa extensiones para el soporte de HTTP, manipulacin y transformaciones XSL. - Incorpora proyectos extra para la explotacin de los datos que almacene, como puede ser Cocoon. - Incorpora un framework del lado del servidor para la creacin de aplicaciones web, basadas totalmente en XML. - Desde un punto de vista econmico, resulta un producto muy ventajoso al sustentarse sobre licencias de tipo: GNU LGPL .
42
43
4.2.2 Lenguajes de consulta XML
4.2.2.1 Xquery - Xpath (http://www.w3.org/XML/Query)

Xquery se presenta como un lenguaje funcional, en vez de ejecutar comandos como lo hara un lenguaje procedural, cada consulta es una expresin a ser evaluada. Las expresiones se pueden combinar para hallar nuevas expresiones. Xquery se basa en los siguientes lenguajes: - Xpath y XQL: De ellos adopta la sintaxis para navegar por documentos jerrquicos. - SQL: (lenguaje relacional). Las clusulas FLWR y operadores como el join. - XML-QL: De este lenguaje adopta la idea de asignar variables para crear nuevas estructuras.
En la pgina del Consorcio W3C aparece una lista de fabricantes de software que ya implementan soluciones basadas en Xquery. Algunos de estos fabricantes: - Berkeley Lab's Nux, an Open source XQuery extension to XOM. - Blackpearl's Blackpearl 4 platform, with an embedded XQuery engine - BEA's Liquid Data
Xquery hace un uso intensivo de Xpath (un lenguaje utilizado para seleccionar porciones de XML); de hecho algunos ven a Xquery como un superconjunto de Xpath. La nueva versin de Xpath (2.0) est siendo desarrollada por el mismo grupo de trabajo y de manera conjunta a la versin 1.0 de Xquery.
- Renmin University of China's OrientX - Sleepycat's Berkeley DB XML 2.0, an embedded native XML database with support for XQuery 1.0 (July 2004 draft), implemented in C++, with interfaces for Java, Python, Perl and PHP. Open source. - Software AG's - Tamino XML Server - Sonic Software's - Stylus Studio 5.0 (XQuery, XML Schema and XSLT IDE)
Ipedo's XML Database v3.0 Microsoft's SQL Server 2005 Express, with XQuery support Neocore's XML management system (XMS): http://www.neocore.com/products/products.htm Oracle's Xquery Technology - Preview
Bluestream Database Software Corp.'s XStreamDB Cerisent's XQE Cognetic Systems's XQuantum GNU's Qexo (Kawa-Query) Compiles XQuery on-the-fly to Java bytecodes. Based on and part of the Kawa framework. An online sandbox is available too. Open source.
44
Sourceforge's eXist. Open source. Sourceforge's XQEngine. Open source. Sourceforge's XQuench. Open source. Worcester Polytechnic Institute's RainbowCore. Java.
45
4.3 Envo y recepcin de informes XBRL

Dado que XBRL es un modelo de XML, el intercambio de ficheros se puede realizar utilizando distintas alternativas. A continuacin se enumeran y describen brevemente. Los servicios web permiten que las aplicaciones compartan informacin y que adems invoquen funciones de otras aplicaciones independientemente de cmo stas se hayan creado, sea cual sea el sistema operativo o la plataforma en que se ejecutan y cules los dispositivos utilizados para obtener acceso a ellas. Existen muchos servicios web implementados con php (lenguaje de programacin no marcado que se ejecuta en el servidor).
Los protocolos que soportan los servicios web se comunican normalmente por el puerto 80 y basndose en HTTP, mtodos GET y PUT. Esto hace que podamos acceder a ellos al igual que lo hacemos en una pgina web. La diferencia entre una pgina web y un servicio web, es que la pgina la visita cualquier individuo interesado, mientras que el servicio slo lo visitan programas que lo requieren.
Se puede realizar un servicio web sencillo en el sistema, pero posiblemente ste no cumplir con estndares de comunicacin, es por eso que debemos de entender que para realizar una correcta funcin de nuestros servicios web es necesario estandarizarlos por medio de protocolos. Existen dos grandes tendencias: XML-RPC Protocolo de llamada de procedimientos remotos (RPC: Remote Procedure Call) y SOAP (Simple Object Access Protocol, Protocolo de acceso a objetos simple). A la hora de programar un servicio web, hay que decidir qu protocolo usar, porque un protocolo es incompatible con el otro. De modo que si programamos el servicio web con XML-RPC, no podremos invocarlo desde un lenguaje de programacin que trabaje con SOAP, como por ejemplo .Net de Microsoft. de todo tipo de servicios web.
La diferencia entre SOAP y XML-RPC es su complejidad. XML-RPC est diseado para ser sencillo. SOAP por el contrario est creado con idea de dar un soporte completo y minucioso Un servicio web se invoca enviando una solicitud web en lenguaje XML y la respuesta es una pgina web cuyo cdigo es XML. Para efectuar dicha invocacin, se realiza directamente desde el cdigo de programacin de la aplicacin cliente y se utilizan rutinas del protocolo cliente (SOAP o XML-RPC) que traducen a XML nuestra llamada, invocan por HTTP el servicio web, descargan el XML resultante y lo procesan convirtindolo en variables resultado.
La siguiente figura muestra de manera simplificada el proceso de envo de un fichero XML. Como puede observarse cualquier cliente realiza la invocacin del servicio web alojado en el servidor, enviando el fichero en formato XML. Dicho fichero es tratado en el servidor y devuel46
to en formato XML al cliente. Una vez el cliente est en posesin del fichero de resultado deber proceder a realizar las acciones de recepcin y tratamiento definidas en posteriores apartados.
Si entramos un poco ms en detalle diremos que en el caso de enviar un mensaje de XMLRPC, ste es una peticin del HTTP-POST. El cuerpo del mismo est en XML, un procedimiento es ejecutado en el servidor y el valor que devuelve est en formato XML. En el caso de SOAP, ste es un protocolo basado en XML que consiste de tres partes: la primera define cul es el mensaje y cmo procesarlo, la segunda es un sistema de reglas de codificacin para expresar tipos de datos definidos y una tercera parte para representar respuestas de llamadas por parte de procedimientos remotos. WSDL y UDDI. Veamos qu significan exactamente.
SOAP, a diferencia de XML-RPC, incluye una infraestructura a su alrededor. No es un mero protocolo de comunicacin entre ordenadores, sino que adems se rodea de trminos como W - WSDL (Web Services Description Language) es un fichero en formato XML que indica al ordenador que lo consulta qu servicios dispone en su sede. Adems de dar una referencia precisa sobre ellos, para poder invocarlos usando los parmetros adecuados. UDDI - UDDI (Universal Description, Discovery, and Integration). UDDI es un servicio web en lnea En la siguiente figura se muestra la relacin de las tecnologas: en lnea, todos ellos perfectamente integrados en una interfaz XML simple.
que se puede utilizar desde las aplicaciones para descubrir de forma dinmica otros servicios
47
La especificacin UDDI, junto con eXtensible Markup Language (XML), Simple Object Access Protocol (SOAP) y Web Services Description Language (WSDL), estn ganando un amplio soporte en el marco de trabajo de los servicios web. Esta tecnologa puede ser muy til en ciertos casos concretos de programacin, adems de ser una tecnologa flexible. Pero por el contrario, a pesar de ser una tecnologa que intenta repartir la carga de trabajo por Internet, sobre el servidor del servicio web, no deja de utilizar el paradigma cliente-servidor (filosofa de sistemas centralizados). Esto nos lleva a que si, por ejemplo, se viniera abajo el registro UDDI, aunque el sistema est replicado ocasionara un cuello de botella en los servidores. Dicho esto, cabe mencionar las siguientes ventajas e inconvenientes: Ventajas:
Ventajas:
- Aportan interoperabilidad entre aplicaciones de software independientemente de sus propiedades o de las plataformas sobre las que se instalen. - Los servicios web fomentan los estndares y protocolos basados en texto, que hacen ms fcil acceder a su contenido y entender su funcionamiento. - Al apoyarse en HTTP, los servicios web pueden aprovecharse de los sistemas de seguridad firewall sin necesidad de cambiar las reglas de filtrado. - Para realizar transacciones no pueden compararse en su grado de desarrollo con los estndares abiertos de programacin distribuida. - Su rendimiento es bajo si se compara con otros modelos de programacin distribuida, tales como RMI o Corba. Es uno de los inconvenientes derivados de adoptar un formato basado en texto. - Al apoyarse en HTTP, pueden esquivar medidas de seguridad basadas en firewall cuyas reglas tratan de bloquear o auditar la comunicacin entre programas a ambos lados de la
Inconvenientes:
Inconvenientes:
Todo sistema de correo electrnico debera garantizar, al menos, que los mensajes lleguen a su destinatario (en ambas direcciones) y que pasen por un punto de recepcin-control que gestione el apartado de seguridad (antivirus, firewall). Adems debera almacenarse una copia de seguridad de cada mensaje recibido en un depsito de gestin centralizado que permita la recuperacin de los documentos.
Otra opcin es la utilizacin del correo electrnico como herramienta de intercambio. Esta herramienta es la aplicacin de Internet que ms se usa en el entorno empresarial debido a su rapidez, facilidad de uso y comodidad.
barrera.
48
Podemos decir que este sistema tiene muchas ventajas entre las que se encuentran las siguientes: - Es una herramienta muy extendida. - Fcil de utilizar y de bajo coste. - No requiere una infraestructura excesivamente compleja. - Es un sistema asncrono, por lo que no se requiere la presencia simultnea de los sistemas comunicantes.
Por el contrario, este sistema suele ser bastante inseguro con lo que las polticas de seguridad deben hacer especial hincapi para evitar la manipulacin que no desea de la informacin. Esto es, se deben implementar mtodos que aseguren la informacin como la utilizacin de encriptacin y/o firmas digitales que cumplan con los estndares (vase apartado de seguridad). Tambin cabe la posibilidad de configurar un servidor seguro de correo. Estos servidores son totalmente funcionales y de alto rendimiento; adems permiten usar un completo abanico de modernas tecnologas y protocolos que mejoran su eficiencia, robustez, flexibilidad y seguridad. Una tercera posibilidad es el uso de un cliente FTP. Este es un protocolo de transferencia de ficheros muy utilizado y fiable, sncrono, ms seguro que el correo electrnico ya que necesitamos los permisos adecuados para realizar las acciones oportunas tales como visualizar, descargar, copiar, etc. y evita la mayora de errores producidos por la codificacin de los distintos protocolos derivados de los programas de correo. Adems, existen muchos clientes FTP con una interfaz visual que facilita el uso de los mismos.
49
4.4 Recepcin de informacin y tratamiento
El proceso de recepcin de ficheros XBRL conlleva una serie de acciones anteriores a su tratamiento y dado que la informacin tratada es de carcter sensible deberan tomarse todas las medidas de seguridad razonables para evitar la manipulacin no autorizada de los datos (sera recomendable que los documentos recibidos vinieran firmados digitalmente por la empresa, auditor o entidad certificadora). En el grfico que se muestra a continuacin se indican de manera simplificada las acciones a realizar una vez se ha recibido el fichero XBRL.
mento y los documentos XLINK para validar la lgica del mismo. A esto hay que aadirle una informe financiero.
disponer del esquema XML que describa la validez de las etiquetas definidas dentro del docu-
El fichero recibido deber ir cifrado en base a las especificaciones de seguridad descritas en el apartado correspondiente a este tema. Por lo tanto, el primer paso a realizar sera el proceso de descifrado que permita obtener un fichero legible para ser tratado. A continuacin, se proceder a realizar la validacin del documento. Para llevar a cabo este proceso se necesita
taxonoma definida o conjunto de archivos XML que describe los elementos lineales en un (Estos conceptos se encuentran definidos ms detalladamente en apartados anteriores en este documento). Una vez que el fichero ha sido validado de acuerdo a las especificaciones se puede proceder a su almacenamiento y/o tratamiento.
El almacenamiento puede realizarse en una Base de Datos relacional o en algn directorio dentro del sistema. Quizs nos interese almacenar el propio fichero una vez recibido o en cambio, primero proceder a su tratamiento y una vez transformado en otro fichero de resultado 50
almacenarlo como un registro de una tabla en Base de Datos. Para obtener informacin acerca del proceso de almacenamiento vase el apartado 4.5. de este mismo documento que lo describe en detalle. los conceptos de XML se podr utilizar la especificacin XSLT (Xml Stylesheets Transformation Language). XSLT es un lenguaje para la transformacin de ficheros XML, que se apoya en XPATH, que es un lenguaje que permite escribir expresiones para la bsqueda de nodos dentro del rbol XML. Dicha transformacin puede generar ficheros tanto en el propio formato XML como html o txt. Adems, se permite la generacin de PDFs o rtf utilizando el lenguaje de especificacin de estilos (xsl-fo). Por otra parte, para realizar el tratamiento del fichero recibido y dado que XBRL se basa en
SAX - SAX (Simple API for XML). Consta de una serie de clases que nos permiten trabajar con un documento XML desde un programa escrito en Java, pudiendo acceder a los datos, comprobar si est bien formado y si tiene un formato vlido. - La principal caracterstica es que el documento se lee secuencialmente de principio a fin, sin cargar todo el documento en memoria. - Ventaja: la eficiencia en cuanto al tiempo y la memoria empleados en el anlisis. - Desventaja: no disponemos de la estructura en rbol de los documentos. - Se necesita un analizador SAX. DOM - DOM (Modelo de Objetos de Documento). Consta de una serie de clases que permiten trabajar con documentos XML desde programas escritos en Java. - La principal caracterstica de DOM es que el documento con el que se trabaja se carga - Ventaja: al disponer de la estructura del documento, permite acceder a los datos en fune incluso crearlos desde cero. - Desventaja: el coste en tiempo. - Se necesita un analizador DOM. entero en memoria, en una estructura de rbol. cin de la jerarqua de elementos, as como modificar el contenido de los documentos
En el caso de estar utilizando tecnologa Java disponemos adems de dos APIs que nos permiten tratar un fichero XML. A continuacin se exponen brevemente las caractersticas fundamentales de cada una de ellas
Del proceso de transformacin del fichero origen obtendremos un fichero de resultado con el formato requerido segn cada caso. El almacenamiento de dicho fichero se realizar en base a las polticas de almacenamiento descritas en el apartado 4.5.
51
4.5 Seguridad
4.5.1 Seguridad en el aplicativo

Restriccin de acceso: Se debera dar acceso al aplicativo slo a los usuarios con permisos para acceder a dicha informacin. Se deberan considerar las siguientes medidas y controles para dar soporte a los requisitos de restriccin de accesos:
Identificacin y Autenticacin: En el apartado de la generacin de instancias deber existir un mecanismo que permita la identificacin de forma inequ voca y personalizada de todo aquel usuario que intente acceder a este apartado. Para ello se podr tener una relacin de usuarios el acceso a dicho apartado. Adems, se debera limitar la posibilidad de intentar reiteradamente el acceso no autorizado a este apartado.
- Establecer mens para controlar los accesos a las funciones del sistema del aplicativo. - Restringir el conocimiento de informacin y de funciones del aplicativo a cuyo acceso los usuarios no estn autorizados. - Controlar los derechos de acceso de los usuarios. - Asegurarse de que las salidas del aplicativo que procesen la generacin de las instancias slo contienen esta informacin y que se envan nicamente a los terminales o lugares autorizados.
con acceso a la aplicacin, clasificados en funcin de su perfil, pudiendo ser uno de los perfiles
da a un usuario. Las contraseas son una forma comn de conseguir la identificacin y la autenticacin de usuario. Esto mismo tambin se puede conseguir por medios criptogrficos y protocolos de autenticacin. inteligentes, minicalculadoras con claves almacenables o bien con tecnologas biomtricas que utilizan caractersticas o atributos nicos de un individuo. Una combinacin de tecnologas y mecanismos, relacionados mediante el establecimiento de un enlace seguro, pueden proporcionar una autenticacin reforzada o ms robusta. Tambin puede conseguirse identificacin y autenticacin con objetos como tarjetas
Distintos procedimientos de autenticacin pueden usarse para materializar la identidad pedi-
Seguimiento de accesos al aplicativo: Cuando se genere la instancia se deber guardar un registro donde se debera identificar el usuario que ha realizado la instancia, la fecha y hora en que se realiz dicha instancia, identificacin del terminal donde se ha generado la instancia si eso es posible, registro de los intentos aceptados y rechazados de acceso al aplicativo y si se ha generado de manera satisfactoria o no la misma.
52
Ubicacin del Aplicativo: El aplicativo de generacin de instancias debera estar ubicado en un servidor con acceso restringido. Adems, nicamente el personal autorizado tendr acceso a las instalaciones donde est ubicado el Servidor.
Limitacin del tiempo de conexin: Las restricciones en los tiempos de conexin ofrecen seguridad adicional para las aplicaciones de alto riesgo. Limitar el periodo de tiempo durante el que se aceptan conexiones desde un terminal reduce la ventana de oportunidad para accesos no autorizados. Backup: Se deberan realizar regularmente copias de seguridad del servidor donde est ubicado el aplicativo.
Pese a todas las medidas de seguridad puede ocurrir un desastre, por tanto es necesario que el Plan de Contingencias incluya un Plan de Recuperacin de Desastres, el cual tendr como objetivo restaurar el Servicio de Cmputo en forma rpida, eficiente y con el menor costo y prdidas posibles.
Plan de Contingencias: El Plan de Contingencias implica un anlisis de los posibles riesgos a los cuales puede estar expuesto nuestro aplicativo y la informacin contenida en los diversos medios de almacenamiento, por lo que se debera realizar un anlisis de los riesgos, cmo reducir su posibilidad de ocurrencia y los procedimientos a seguir en caso de que se presentara el problema.
53
4.5.2 Seguridad en la instancia generada

Acceso Lgico Restringido: Se debera dar acceso al directorio donde se guarden las instancias slo a los usuarios con permisos para acceder a dicha informacin. Se deberan considerar las siguientes medidas y controles para dar soporte a los requisitos de restriccin de accesos: - Restringir el conocimiento de esta informacin a los usuarios autorizados. - Controlar los derechos de acceso de los usuarios.
Deber existir un mecanismo que permita la identificacin de forma inequ voca y personalizada de todo aquel usuario que intente acceder a este directorio. Para ello se podr tener una relacin de usuarios con acceso al directorio en funcin de su perfil. Adems se debera limitar la posibilidad de intentar reiteradamente el acceso no autorizado a este directorio.
Distintos procedimientos de autenticacin pueden usarse para materializar la identidad pedida a un usuario. Las contraseas son una forma comn de conseguir la identificacin y la autenticacin de usuario. Esto mismo tambin se puede conseguir por medios criptogrficos y protocolos de autenticacin. Backup de la Carpeta: Se deberan hacer regularmente copias de seguridad de las instancias que se han generado. Adems se debera comprobar que las copias de seguridad realizadas han finalizado correctamente.
Seguridad Fsica del Equipo: Se debera tener un control sobre la mquina fsica donde se han guardado las instancias generadas. Para ello se recomiendan usar permetros de seguridad para proteger este recurso. El acceso a la sala donde se encuentre el recurso ser controlado y restringido nicamente al personal autorizado. Se deben usar controles de autenticacin, por ejemplo, tarjetas con nmero de identificacin personal, para autorizar y validar el acceso. Se aconseja mantener un rastro auditable de todos los accesos, con las debidas medidas de seguridad. Sera conveniente revisar y actualizar regularmente los derechos de accesos al lugar donde este ubicado dicho recurso.
Adems el recurso debera estar fsicamente protegido de las amenazas y riesgos del entorno para protegerlo contra prdidas o daos. Tambin se recomienda considerar su instalacin y disponibilidad. Deberan establecerse medidas o controles especiales contra riesgos de accesos no autorizados y para proteger los sistemas de apoyo, como la alimentacin interrumpida o la infraestructura de cableado.
54
Cifrado de la Instancia: Es una tcnica criptogrfica que puede utilizarse para proteger la confidencialidad de la informacin. usarn.
El nivel adecuado de proteccin ha de basarse en una evaluacin del riesgo y tener en cuenta el tipo y calidad del algoritmo de cifrado y la longitud de las claves criptogrficas que se En la implantacin de la poltica criptogrfica es importante tener en cuenta las regulaciones y restricciones nacionales que se aplican en distintas partes del mundo para el uso de las tcnicas criptogrficas y el cifrado de las transmisiones internacionales de los datos.
55
4.5.3 Seguridad en la transmisin de las instancias

es necesario lo siguiente Para proceder a tener un canal seguro es necesario lo siguiente: Autenticacin en los extremos - Autenticacin en los extremos. Confidencialidad - Confidencialidad : Asegurarse de que la informacin es accesible slo para aquellos usuarios autorizados. Integridad - Integridad: Garanta de la exactitud y completitud de la informacin y los mtodos de su procesamiento. En la prctica, verificar que la informacin suministrada en destino es idntica a la generada en origen. Disponibilidad - Disponibilidad: Asegurar que los usuarios autorizados tienen acceso, cuando lo requiera, a la informacin y sus activos asociados. No Repudio - No Repudio: Cualidad por la que ninguno de los extremos de una comunicacin pueda rechazar la autora de un envo, as como del contenido del mismo.
- Certificado Digital: Fichero con informacin sobre el titular del mismo que le permite identificarse ante un sistema o aplicacin. El Certificado Digital proporciona Autenticacin. - Cifrado: Se transforman los datos para que slo sean inteligibles a los usuarios autorizados. - Firma Digital: Secuencia de datos digitales aadidos a una transmisin / instancia que permiten identificar unvocamente al autor de la misma. Proporciona autenticacin e integridad. - Control de Accesos: No permiten el acceso fsico o lgico a la informacin a usuarios no autorizados. - Mecanismos de Integridad: Informacin de control aadida en una transmisin que permite detectar si se ha producido alguna modificacin o error en el contenido de la informacin enviada. - Control de encaminamiento: Se utilizan los sistemas de encaminamiento para proteger la informacin. La siguiente tabla relaciona los mecanismos con los servicios de seguridad: Mecanismos de seguridad:
56
- Criptografa Los mecanismos cifrado, firma digital, certificado digital e integridad utilizan criptologa para su implementacin. La criptografa es la ciencia que hace uso de mtodos y tcnicas matemticas con el objeto principal de cifrar y/o proteger un mensaje o instancia por medio de un algoritmo, usando una o ms claves. Esto da lugar a diferentes tipos de sistemas de cifrado que permiten asegurar estos cuatro aspectos de la seguridad informtica: la confidencialidad, la integridad, la disponibilidad y el no repudio de emisor y receptor. Las tcnicas de criptografa se pueden clasificar en dos segn el tipo de clave utilizado: - Criptografa simtrica - Criptografa de clave pblica o asimtrica Simtrica: Se caracteriza por usar la misma clave para cifrar y descifrar. Toda la seguridad est basada en la privacidad de esta clave secreta, llamada simtrica porque es la misma para el emisor y el receptor. Estos sistemas slo permiten confidencialidad y no autenticacin ni firma digital. Los algoritmos simtricos son ms sencillos que los asimtricos, por ese motivo los procesos son ms simples y rpidos. Los algoritmos ms utilizados son: DES, TDES, IDEA, RC5, RIJNDAEL. Asimtrica: Est basada en la utilizacin de claves distintas para cifrar y descifrar; una de ellas se hace pblica y la otra es privada de cada usuario. As todos los usuarios tienen acceso a las claves
pblicas, pero nicamente ellos conocen su clave privada. Estos sistemas se pueden utilizar para confidencialidad, autenticacin y firma digital. El principal inconveniente de estos sistemas es la dificultad de implementacin y la lentitud de proceso. La ventaja es que implementan servicios de autenticacin y firma, y adems no tiene problemas con la distribucin de claves: la clave pblica puede ser visible por cualquiera y la privada no se transmite nunca. El algoritmo ms utilizado es el RSA. nicamente para firma digital tambin se utiliza el algoritmo DSS que ha sido adoptado como estndar por el NIST. Para distribuir claves simtricas tambin se utiliza el algoritmo Diffie-Hellman, pero no sirve para confidencialidad, autenticacin ni firma digital.
57
4.5.4 Soluciones para el canal de comunicacin

4.5.4.1 VPNs (Virtual Private Networks)
Una red privada virtual (VPN) es la extensin de una red privada que incluye vnculos de redes compartidas o pblicas como Internet. Con una red privada virtual, se puede enviar datos entre dos equipos a travs de una red compartida o pblica de forma que emula un vnculo privado punto a punto. Esto se consigue encapsulando los datos con un encabezado que proporciona la informacin de enrutamiento que permite a los datos recorrer la red pblica hasta alcanzar su destino como si de un tnel se tratara. Los datos se cifran para asegurar la confidencialidad en la misma parte de la conexin en la que se encapsulan. Gracias al acceso remoto y a las conexiones enrutadas, una organizacin puede utilizar conexiones VPN para realizar conexiones a larga distancia o lneas concedidas para conexiones locales o con un proveedor de servicios de Internet (ISP).
La seguridad en la VPN de acceso remoto se mejora a travs de una autenticacin segura utilizando el esquema de certificados electrnicos. Tipos de VPNs:
Tienen las ventajas de los mecanismos de seguridad que utilizan los cortafuegos, incluyendo el acceso restringido a la red interna. Tambin realizan la traduccin de direcciones (NAT). Estos satisfacen los requerimientos de autenticacin fuerte. -- Siistemas Basados en Software: Estos sistemas son ideales para las situaciones donde los dos S stemas Basados en Software: puntos de conexin de la VPN no estn controlados por la misma organizacin, o cuando los diferentes cortafuegos o routers no son implementados por la misma organizacin. Con este tipo, el trfico puede ser enviado a travs de un tnel, en funcin de las direcciones o protocolos, en cambio en los VPNs por hardware, todo el trfico es enrutado por el tnel. Podemos hacer un enrutamiento inteligente de una manera mucho ms fcil. Las dos tecnologas ms utilizadas para crear VPNs, en realidad son diferentes protocolos o conjuntos de protocolos, son PPTP y L2TP.
de usar. Ofrecen un gran rendimiento, porque no malgastan ciclos de procesador haciendo funcionar un Sistema Operativo. Es hardware dedicado, muy rpido y de fcil instalacin. -- Siistemas Basados en Cortafuegos: Estos se implementan con software de cortafuegos (Firewall). S stemas Basados en Cortafuegos:
- Sistemas Basados en Hardware: - Sistemas Basados en Hardware: Estos sistemas son routers que se cifran. Son seguros y fciles
PPTP: Point to Point Tunneling Protocol PPTP es un protocolo desarrollado por Microsoft y disponible en todas las plataformas Windows. Es sencillo y fcil de implementar pero ofrece menor seguridad que L2TP.
58
y son desencriptados en el destino. Como todos los datos en una conexin fluyen dentro del tnel, los datos son invisibles al resto del mundo. La encriptacin de datos dentro del tnel da un nivel adicional de seguridad. -- Fiilltrado de Paquetes PPTP: Esta opcin incrementa el rendimiento y fiabilidad de la seguridad F trado de Paquetes PPTP: de red si est activada en el servidor PPTP. etc. Se implementa sobre IPSec y proporciona altos niveles de seguridad. Se pueden usar certificados de seguridad de clave pblica para cifrar los datos y garantizar la identidad de los usuarios de la VPN. L2TP: Layer Two Tunneling Protocol Se trata de un estndar abierto y disponible en la mayora de plataformas Windows, Linux, Mac,
Hay tres reas en la seguridad PPTP que son la autenticacin, encriptacin de datos y el filtrado de paquetes PPTP. -- Autentiicaciin Autent cac n -- Encriiptaciin de datos: Los paquetes de red son encriptados en la fuente, viajan a travs del tnel Encr ptac n de datos:
Comparativa entre PPTP y L2TP: - Con PPTP, el cifrado de datos comienza despus de que la conexin se procese (y, por supuesto, despus de la autentificacin PPP). Con L2TP/IPSec, el cifrado de datos empieza antes de la conexin PPP negociando una asociacin de seguridad IPSec. - Las conexiones PPTP usan MPPE, un mtodo de cifrado basado en el algoritmo de encriptacin Rivest-Shamir-Aldeman (RSA) RC-4, y usa llaves de 40, 56 o 128 bits. Las conexiones L2TP/IPSec usan Data Encryption Standard (DES), con llaves de 56 bits para DES o tres llaves de 56 bits para 3-DES. Los datos se cifran en bloques (bloques de 64 bits para el caso de DES). de autentificacin basado en PPP. Las conexiones L2TP/IPSec requieren el mismo nivel de autentificacin a nivel de usuario y, adems, nivel de autentificacin de mquina usando certificados digitales. - Las conexiones PPTP requieren slo autentificacin a nivel de usuario a travs de un protocolo
- Todos los tipos IP y Servicios son soportados. - Una vez que el intercambio de clave se completa, muchas conexiones pueden utilizar el tnel establecido. - Misma tecnologa base para trabajar entre cliente-cliente, cliente-site, site-site.
Tecnologa de VPN: Seguridad sobre VPN: - Ipsec con encriptacin - SSL 3.0 TLS con encriptacin -- IPSEC con ENCRIPTACIN: Es el ms popular dentro de las VPNs. Soporta una amplia variedad IPSEC con ENCRIPTACIN: de algoritmos de encriptacin (DES, 3DES,AES, RC4), as como los mecanismos de integridad de los datos(MD5, SHA-1). Tambin soporta certificados digitales X.509. Tiene una amplia variedad de soluciones en mltiples modos: Cliente, Servidor y Gateways. Venta as y Desventa as de uso de VPN IPSEC: Ventajjas y Desventajjas dell uso de VPN IPSEC: Venta as: Ventajjas:
59
- Para las VPN Cliente se requiere una instalacin software en el cliente. No todos los sistemas operativos requeridos por el cliente pueden soportarlo. - Para las VPN Cliente se requiere la configuracin cliente antes de que el tnel sea establecido. - La conectividad puede ser afectada negativamente para NAT o mecanismos proxy entre el cliente y el gateway. - La conectividad puede ser afectada negativamente para firewalls entre el cliente y el gateway. - SSL VPN (CLIENTLESS VPNs): - SSL VPN (CLIENTLESS VPNs): Actualmente la tecnologa SSL VPN (tambin llamada Clientless VPN) est en competencia con la tradicional IPSec VPN para el acceso remoto o el uso frecuente de la extranet. SSL VPN es bsicamente la posibilidad de realizar VPN desde una interface web, con la posibilidad de acceder, en forma cifrada, a determinados recursos de la empresa. Soporta una amplia variedad de algoritmos de encriptacin (DES, 3DES, AES, RC4, RSA, DSA), as como los mecanismos de integridad de los datos (MD5, SHA-1). Ventajas y Desventajas del uso de SSL VPN: Ventajas y Desventajas del uso de SSL VPN: Ventajas: Ventajas: - La mayora de las aplicaciones ms populares de Cliente / Servidor soportan SSL. - Opera transparentemente a travs de NAT y mecanismos proxy. Desventajas: Desventajas: - Https cliente es soportado por todos los sistemas operativos.
- Soporta tecnologa de autenticacin fuerte e integracin del directorio. Desventajas: Desventajas:
- Solo soporta servicios TCP, y a menudo slo HTTP POP3/IMAP/SMTP sobre SSL. - No usado para VPNs site-to-site. - Los datos son seguros en transito, pero no hay control sobre la seguridad de los datos en el sistema del cliente. - Mltiples Sesiones SSL pueden ser requeridas para una sesin. SSL VPN es til cuando: - El trfico es HTTP o e-mail. - Se requiere acceso a la informacin desde cualquier dispositivo (laptop, PC, PDA) desde cualquier parte del mundo (oficina, casa, cybercaf). - No es posible instalar software de acceso VPN en el PC remoto. IPSEC VPN es til cuando: -La organizacin necesita disponer de una infraestructura que permita el trfico de gran variedad de protocolos, no slo HTTP o e-mail. - La organizacin tiene control sobre los dispositivos de acceso remoto. - Existen fuertes restricciones de seguridad en el acceso remoto (Por ejemplo: no permitir el acceso desde cybercafs). 60 hemos elaborado esta breve lista con las ventajas de una y otra tecnologa: La pregunta que se plantean es Debo utilizar SSL VPN o IPSEC VPN?. Es por ellos que
4.5.4.2 Web cifrada

Permite el establecimiento de un canal seguro de comunicacin sobre HTTP en el mbito de una aplicacin. SSL proporciona sus servicios de seguridad sirvindose de dos tecnologas de cifrado distintas: criptografa de clave pblica (asimtrica) y criptografa de clave secreta (simtrica). Para el intercambio de los datos entre el servidor y el cliente, utiliza algoritmos de cifrado simtrico, que pueden elegirse tpicamente entre DES, triple-DES, RC2, RC4 o IDEA. Para la autenticacin y para el cifrado de la clave de sesin utilizada por los algoritmos anteriores, usa un algoritmo de cifrado de clave pblica, tpicamente el RSA. La clave de sesin es la que se utiliza para cifrar los datos que vienen de l y van al servidor una vez establecido el canal seguro. Primero se deben establecer los parmetros que se utilizarn en la sesin a travs de un handshake o intercambio de claves. Durante el handshake se cumplen varios propsitos: se hace autenPara establecer una comunicacin segura utilizando SSL se tienen que seguir una serie de pasos. En la actualidad el protocolo ms utilizado es el SSL.
ticacin del servidor y opcionalmente del cliente a travs de certificados, se determina qu algoritmos de criptografa sern utilizados y se genera una clave secreta para ser utilizada durante el intercambio de mensajes subsiguientes durante la comunicacin SSL:
de criptografa puede utilizar y solicita una verificacin de la identidad del servidor. El cliente env a el conjunto de algoritmos de criptografa y compresin que soporta y un nmero aleatorio. El propsito del nmero aleatorio es para que en caso de que el servidor no posea un certificado para comprobar su identidad, an se pueda establecer una comunicacin segura utilizando un conjunto distinto de algoritmos. Dentro de los protocolos de criptografa hay un protocolo de intercambio de clave que define cmo cliente y servidor van a intercambiar la informacin, los algoritmos de clave secreta que definen qu mtodos pueden utilizar y un algoritmo de hash de una sola va. Hasta ahora no se ha intercambiado informacin secreta, slo una lista de opciones. -- Server Hellllo: El servidor responde enviando su identificador digital, el cual incluye su clave pbliServer He o: ca, el conjunto de algoritmos criptogrficos y de compresin y otro nmero aleatorio. La decisin de qu algoritmos sern utilizados est basada en el ms fuerte que, tanto cliente como servidor, soporten. En algunas situaciones el servidor tambin puede solicitar al cliente que se identifique solicitando un identificador digital. -- Aprobaciin dell Clliiente: El cliente verifica la validez del identificador digital o certificado enviaAprobac n de C ente: do por el servidor. Esto se lleva a cabo descifrando el certificado utilizando la clave pblica del emisor y determinando si ste proviene de una entidad certificadora de confianza. Despus, se hace
- Client Hello: - Client Hello: El saludo de cliente tiene por objetivo informar al servidor de qu algoritmos
61
una serie de verificaciones sobre el certificado, tales como fecha, URL del servidor, etc. Una vez se ha verificado la autenticidad de la identidad del servidor, el cliente genera una clave aleatoria y la cifra utilizando la clave pblica del servidor y el algoritmo criptogrfico y de compresin seleccionado anteriormente. Esta clave se le enva al servidor y en caso de que el handshake tenga xito ser utilizada en el envo de futuros mensajes durante la sesin. -- Veriifiicaciin: En este punto ambas partes conocen la clave secreta, el cliente porque la gener Ver f cac n: y el servidor porque le fue enviada utilizando su clave pblica (la nica forma posible de descifrarla es utilizando la clave privada del servidor). Se hace una ltima verificacin para comprobar si la informacin transmitida hasta el momento no ha sido alterada. Ambas partes se envan una copia de las anteriores transacciones cifrada con la clave secreta. Si ambas partes confirman la validez de las transacciones, el handshake se completa, de otra forma se reinicia el proceso. Ahora ambas partes estn listas para intercambiar informacin de manera segura utilizando la clave secreta acordada y los algoritmos criptogrficos y de compresin. El handshake se realiza slo una vez y se utiliza una clave secreta por sesin. Intercambio de datos: - Intercambio de datos: Ahora que se ha establecido un canal de transmisin seguro SSL, es posible el intercambio de datos. Cuando el servidor o el cliente desean enviar un mensaje al otro, se genera un resumen (utilizando un algoritmo de hash de una va acordado durante el handshake), cifran el mensaje y el resumen y se enva, cada mensaje es verificado utilizando el resumen. Terminacin de una sesin SSL: - Terminacin de una sesin SSL: Cuando el cliente deja una sesin SSL, generalmente la aplicacin presenta un mensaje advirtiendo que la comunicacin no es segura y confirma que el cliente efectivamente desea abandonar la sesin SSL. Ventajas y Desventajas del uso de web cifrada: - Ventajas y Desventajas del uso de web cifrada: Venta as: Ventajjas: - Facilidad en el despliegue de esta solucin. - Mnimos requisitos (No necesidad de Cliente) para el establecimiento de la sesin. Desventajas: Desventajas:
- Slo utilizable en el mbito de una aplicacin Web (No puede utilizarse para cifrado de otros protocolos como POP3, FTP, etc.).
62
4.5.5 Herramientas
Algunas herramientas para la seguridad sobre XML: - XML Security suite (https://secure.alphaworks.ibm.com/tech/xmlsecuritysuite) Es una herramienta que proporciona caractersticas de la seguridad tales como firma digital, cifrado, y control de acceso para los documentos de XML. Estas caractersticas estn ms all de la capacidad de los protocolos de la seguridad del nivel transporte SSL. Cmo trabaja? Tres tecnologas se incluyen en XML Security suite: - Puesta en prctica de la firma Digital basada en XML-Signature Syntax and Processing por la puesta en prctica del cifrado de W3C/IETF. - XML basada en XML Encryption Syntax and Processing. - XML Access Control Language and implementation. - VORDELDIRECTOR - VORDELDIRECTOR (http://www.vordel.com/products/vordeldirector/index.html) VordelDirector proporciona los servicios de seguridad discretos que se utilizan a travs de la red. Estos servicios de seguridad incluyen el cifrado, firma digital, amenaza-anlisis de XML, de la emisin y de la validacin simblica de la seguridad, de la autentticacin, de la autorizacin y del logging. Los servicios de seguridad proporcionados por VordelDirector se disean para ser parte de los servicios web en una Arquitectura orientada a Servicios (SOA). Estos servicios de seguridad son utilizados por usos mltiples, incluyendo las entradas de XML, los usos basados en .NET y los usos basados Java. VordelDirector enva con dos aplicaciones que hagan uso de sus servicios de seguridad. El primero es un proxy que acta en trfico de XML en la red. El segundo uso es un plug-in del web server que intercepta XML en un web server. Ambas aplicaciones hacen cumplir reglas de la seguridad sobre trfico de XML. - VORDELSECURE - VORDELSECURE (http://www.vordel.com/products/vordelsecure/index.html) VordelSecure es un gateway en XML, que es un elemento intermediario en lnea que filtra el trfico XML segn un sistema de reglas configurables de la seguridad. Protege sistemas de XML, tales como servicios web, asegurndose de que solamente los usuarios y aplicaciones correctas - enviando los datos correctos - pueden conectar con ellos. Cuando est desplegada directamente detrs de cortafuegos de red en una red DMZ (zona desmilitarizada), una entrada de XML a menudo se llama un cortafuego de XML . VordelSecure se puede desplegar como software o como aplicacin del hardware, disponible a travs de los socios de la aplicacin de la compaa.
63
4.5.6 Bibliografa
-VPN Technologies: Definitions and Requirements. -IPSEC Versus Clientless VPN for Remote Access.
-Hackers 3: Secretos y soluciones para la seguridad de redes.
-Criptografa y Seguridad en Computadores. Manuel Jos Lucena Lpez
-Anlisis de Seguridad de la familia de protocolos TCP/IP y sus servicios asociados. Ral Siles Pelez. -UNE-ISO/IEC 17799: Cdigo de buenas prcticas para la Gestin de la Seguridad de la Informacin. -Virtual Private Networks (VPN /PPTN) http://www.helmig.com/j_helmig/vpn.htm
-Understanding Virtual Private Networks (VPN) http://www.sans.org/infosecFAQ/encryption/understanding_VPN.htm -Understanding PPTP and VPNs http://www.aliceinwondeland.com/library/website_archives/rhino9/pptp.htm -PoPToP The PPTP Server for Linux http://poptop.lineo.com
-PPTP http://www.cas.mcmaster.cal.~wmfarmer/SE-4C03-01/papers/Silva-PPTP.htm -Acceso remoto por VPN (Red Privada Virtual) http://www.uv.es/ciuv/cat/vpn
-Cisco Layer 2 Tunnel Protocol http://www.cisco.com/warp/public/cc/pd/iosw/tech/l2pro_tc.htm -VPN FAQ http://kubarb.phsx.ukans.edu/~tbird/vpn/FAW.html
64
4.6 Arquitectura XBRL
4.6.1 Arquitectura de referencia

XBRL es una derivacin de XML (eXtensible Markup Language). XML, como formato estndar de comunicacin independiente de las plataformas, ha sido diseado para facilitar el intercambio de informacin entre aplicaciones a travs de las redes corporativas o en Internet. De esta manera, soportado prcticamente por todos los proveedores de software, XML se est imponiendo como el principal facilitador para la transferencia de datos.
XBRL se ha creado especficamente para optimizar la tecnologa XML en su aplicacin a la cadena de distribucin de informacin financiera.
Una aproximacin inicial basada en los primeros pasos que se estn dando para la implantacin de XBRL como estndar para intercambio de informacin financiera, fundamentalmente impulsada por los organismos reguladores, podra hacer pensar en un escenario en el que hay entidades que reciben datos XBRL (reguladoras) y otras que son las que envan dichos datos (reguladas).
Sin embargo, un anlisis ms profundo pone de manifiesto que aquella entidad que ha de reportar a un regulador, a su vez puede estar recibiendo datos de sus subsidiarias, y que aquel organis65
mo regulador que recopila informes de sus entidades reguladas, ha de consolidar datos y reportarlos a otro regulador de mbito ms global, lo que significa que cualquier organizacin que procesa datos financieros es en potencia un eslabn de una cadena de distribucin de informacin financiera, es decir, podra recibir, generar, manipular, consolidar y publicar informes financieros en formato XBRL. Por lo tanto, las organizaciones requieren sistemas que respondan completamente a estas necesidades.
Por lo tanto, cualquier arquitectura diseada para la gestin y procesamiento de datos en formato XBRL debe soportar las fases esenciales del proceso de reporting financiero: - Creacin, distribucin, obtencin y manejo de mltiples taxonomas. - Creacin, publicacin, recepcin, validacin e interpretacin de instancias. - Repositorio para almacenamiento y bsqueda. Adicionalmente, la arquitectura puede incluir elementos complementarios:
- Mecanismos de seguridad: Si bien es cierto que la especificacin XBRL no proporciona ninguna directiva ni referencia sobre mecanismos de seguridad, las comunicaciones de la informacin que se intercambia en formato XBRL requieren, en la mayor parte de los casos, cumplir con estrictos requerimientos de seguridad que garanticen la confidencialidad, la integridad, la autenticidad y el no repudio de los datos. - Herramientas para el desarrollo de taxonomas en un entorno colaborativo, permitiendo gestionar completamente el ciclo de vida de las mismas. - Herramientas de monitorizacin y control de los procesos de tratamiento de informes XBRL. - Adaptadores para la extraccin y conversin de datos en formato no XBRL a XBRL. - Funciones de anlisis de la informacin en XBRL. - Proceso en batch de instancias XBRL.
66
Grficamente:
La arquitectura funcional descrita anteriormente ha de estar sustentada por una arquitectura tcnica que responda a los requerimientos de escalabilidad y rendimiento necesarios. A continuacin se presenta una propuesta de arquitectura tcnica de referencia que cubre dichos requisitos. Se caracteriza por su diseo modular y por su orientacin a servicios.
67
Desglosando la arquitectura por niveles:

- Escritorio XBRL:
- Escritorio XBRL: Agrupa e integra herramientas XBRL ejecutables en puesto cliente para la creacin y edicin de taxonomas e instancias, as como otras utilidades relacionadas. Estas herramientas pueden trabajar en modo local o en conexin con el repositorio de documentos XBRL residente en la parte servidora (WebDAV). - Cliente Web: - Cliente Web: Interfaz de usuario principal, proporcionando: - Gestin y control de los servicios y operaciones directamente relacionados con el proceso de documentos XBRL. - Herramientas para el diseo, generacin y manejo de informes. - Opciones de administracin y operacin del sistema. - Canales de acceso: - Canales de acceso: Mecanismos implementados para la recepcin y envo de instancias XBRL, as como para la descarga y distribucin de taxonomas XBRL. Debe soportar protocolos tales como SMTP, FTP y HTTP(S) y proporcionar un conjunto de servicios web para la distribucin de datos. - Procesador XBRL: - Procesador XBRL: Es el ncleo de la arquitectura; provee los mecanismos fundamentales para el procesado de los documentos XBRL. - Servicios de infraestructura: - Servicios de infraestructura: Agrupa todos aquellos servicios que soportan las funcionalidades no estrictamente XBRL de la arquitectura tales como: - Notificaciones, eventos y logs. - Mecanismos de seguridad y control. - Servicios de repositorio XBRL: - Servicios de repositorio XBRL: Almacenamiento de documentos XBRL, tanto taxonomas como instancias, con funciones de gestin de histricos, control de versiones y buscador de datos. La disponibilidad y caractersticas de estos servicios dependen del tipo de almacenamiento implementado como repositorio, que puede ser: - Repositorio de objetos. - Base de Datos relacional. - Repositorio de datos XML. - Sistema de ficheros. El nivel de granularidad proporcionado por el repositorio tambin depende del tipo de almacenamiento. As puede proporcionar granularidad a nivel de fichero (esquema y linkbases) o llegar al nivel de elemento de taxonoma. Debe contemplarse tambin el almacenamiento de casos de prueba de las taxonomas, en el mismo repositorio en el que stas residan o en otro especfico. - Servidor de aplicaciones/Orquestador: El uso de un servidor de aplicaciones u orquestador es Servidor de aplicaciones/Orquestador: opcional, dependiendo de que los mdulos incluidos en la arquitectura lo requieran o no. - Bus de datos: - Bus de datos: Bajo el control del servidor de aplicaciones u orquestador, aglutina todas las interfaces con sistemas externos, tales como Mainframe, sistemas de Datawarehouse, ERPs, Business Intelligence, etc. Proporciona mecanismos de routing, transporte y adaptadores para el mapeo, extraccin de datos no XBRL y su transformacin a XBRL. 68
4.6.2 Rendimiento
Las arquitecturas diseadas para el tratamiento de informes en formato XBRL deben ser capaces de procesar grandes volmenes de datos proporcionando un rendimiento adecuado. Consideraciones a tener en cuenta respecto al volumen de datos: - En la definicin de taxonomas se tiende a crear DTSs (Discoverable Taxonomy Set) con mltiples niveles de importacin y, en algunos casos, con modelos de datos complejos. - Se estn definiendo taxonomas internacionales con muchos elementos (por ejemplo, la taxonoma IFRS-GP tiene ms de 4.000). - Se pueden construir instancias con mltiples contextos. - Para un mismo informe financiero, el reporting en XBRL representa un incremento en volumen sobre el reporting tradicional (texto plano) en una relacin del orden de 3 a 1. - Si bien los procesos de reporting financiero no implican un trfico muy intenso de datos, s que tienden a concentrarse en unas fechas concretas. Por lo tanto, hay que prever el procesamiento simultneo de instancias XBRL de gran tamao. Recomendaciones de diseo para optimizar el rendimiento de las aplicaciones XBRL: - Emplear procesadores XBRL que proporcionen: - Posibilidad de reutilizacin de modelos de datos de taxonomas o, expresado de otra manera, mecanismos de cach de taxonomas en memoria: La creacin en memoria del modelo de datos relativo a un DTS es uno de los procesos ms pesados asociado al tratamiento de documentos XBRL. Mediante este mecanismo la taxonoma se carga una vez en memoria, estando disponible para procesar todas las instancias vinculadas a ella. - Mecanismos de serializacin/deserializacin: Una alternativa interesante a la cach de taxonomas es su almacenamiento como objetos serializados. Segn estudios realizados, serializada (deserializacin) es directamente proporcional al nmero de enlaces de sus linkbases. - Posibilidad de precompilacin de esquemas XML. - Mecanismos de resolucin eficaces para resolver el acceso y salvado de documentos XBRL. - Empleo del parser XML (DOM o SAX) ms ptimo para cada situacin. - Procesar nicamente los linkbases que sean necesarios para cada situacin. - En taxonomas que importen a otras, inhabilitar los clculos heredados y que no tengan sentido en la nueva taxonoma (mediante el atributo use = prohibited en los arcos de los roles de clculo a inhabilitar). De esta manera, aunque el tamao del linkbase de clculo aumente, el tiempo de validacin de las instancias disminuye considerablemente. el tiempo de lectura de una taxonoma es directamente proporcional al cuadrado del nmero de los enlaces de sus linkbases, mientras que el tiempo de lectura de una taxonoma
69
A continuacin se muestra una serie de grficas que presentan el comportamiento tpico - en trminos de tiempo de respuesta en funcin del nmero de elementos- de algunos de los procesos ms habituales que se realizan con documentos XBRL:
- Seleccionar el tipo de repositorio a utilizar para el almacenamiento de documentos XBRL valorando las prestaciones de rendimiento que proporciona para el manejo de datos XML y XBRL. - Disear arquitecturas escalables. - Minimizar la longitud de las etiquetas XML/XBRL en el diseo de hojas de estilo (XSLT) diseadas para la transformacin de documentos XBRL.
1 1 Carga (y validacin) de taxonoma en memoria.
2 2 Carga (y validacin) de instancia en memoria.
70
3 Serializacin de una taxonoma.

3
4 Deserializacin de una taxonoma.

4
71
4.7 Dimensiones
4.7.1 Introduccin
La mayor parte de las taxonomas definidas hasta ahora estaban limitadas a estructuras bidimensionales, a travs del uso de tuplas, o estructuras mono-dimensionales, mediante el uso de listas jerrquicas de conceptos. En Enero de 2005, el Comit Europeo de Supervisores Bancarios hizo pblico lo que se conoce como Common Reporting Framework (COREP COmmon REPorting) por el que las instituciones de crdito y compaas inversoras reportarn informacin relativa a sus ratios de solvencia bajo la nueva directiva de requisitos de capital. La taxonoma COREP se caracteriza por un modelo de datos basado necesariamente en una estructura de taxonoma dimensional. Es por esto, por lo que el Consorcio de XBRL Internacional decidi desarrollar lo que hoy se conoce como la Especificacin de Dimensiones. Otras taxonomas en las que se hace uso de esta nueva especificacin son FINREP, FINancial REPorting framework y PGC 90, Plan General Contable 1990. Ninguna taxonoma desarrollada en XBRL haba presentado tales requisitos hasta ese momento.
Una taxonoma dimensional permite definir por cada concepto distintas dimensiones, las cuales representan jerarquas de informacin de un determinado aspecto. Ejemplo: Representacin del concepto Total Ventas por productos y por pases.
72
4.7.2 Descripcin de la Especificacin de dimensiones 1.0

Actualmente, la versin publicada de esta especificacin es XBRL Dimensions 1. 0 Candidata a Recomendacin 3 (XDT-CR3-2006-04-26.rtf). Desarrollada por el Consorcio de XBRL Internacional, se encuentra disponible en diferentes formatos en la web: http://www.xbrl.org/SpecRecommendations/. El documento se compone de las siguientes partes:
La especificacin de dimensiones 1.0 es una extensin de la especificacin XBRL 2.1. Est desarrollada de acuerdo a los requisitos de XBRL 2.1. Los documentos de instancia XBRL que contienen informacin dimensional pueden ser procesados sin ningn error por cualquier validador que es capaz de procesar correctamente XBRL.
cacin. - Taxonomas dimensionales: en este apartado se describe la arquitectura utilizada para desarrollar taxonomas dimensionales. Asimismo, se definen todos los conceptos y relaciones a utilizar en una taxonoma dimensional. - Uso de dimensiones en instancias: una instancia XBRL cuyo DTS contenga relaciones dimensionales de acuerdo a lo especificado en el apartado anterior, deber ser validada de acuerdo a las reglas que se describen en este captulo.
- Introduccin: donde se explica el propsito del documento, relacin con otros documentos, terminologa as como los espacios de nombres (namespaces) utilizados en la especifi-
73
4.7.3 Taxonomas primarias (Primary Taxonomies)

Son taxonomas XBRL cuyo DTS no tiene elementos dimensionales ni arcos definidos en la Especificacin de Dimensiones. Taxonomas que no contienen informacin dimensional pueden ser extendidas para aadir dimensiones. Con el trmino de taxonoma primaria se hace referencia a un DTS de elementos que pueden ser reportados en una instancia XBRL.
74
4.7.4 Taxonomas domain-member (Domain Member Taxonomies)

Existen dos tipos de taxonomas dimensionales: - Typed Dimensional Taxonomies: definen restricciones de los contenidos en el segmento o en el escenario. - Explicit Dimensional Taxonomies: son aqullas cuyos elementos XBRL conforman un conjunto discreto de miembros. Este conjunto se denomina dominio.
Las instancias XBRL pueden tener un nmero indeterminado de dimensiones, posibilitando as cualquier combinacin de los miembros de sus dominios tanto en el escenario como en el segmento.
75
4.7.5 Taxonomas template (Template Taxonomies)

Importa tanto las taxonomas primarias como las taxonomas domain-member y aade las estructuras dimensionales que sern utilizadas en la instancia XBRL. Por convenio, una taxonoma que importa taxonomas primarias y domain-member y define toda la informacin
dimensional necesaria se denomina taxonoma template.
Una taxonoma template define hipercubos. Un hipercubo describe el producto cartesiano de cero o ms dimensiones. Cada dimensin est definida por cero o ms dominios y los dominios estn formados por miembros.
Ejemplo: Ingresos por provincias y por productos. Se trata de un hipercubo con tres dimensiones, con un elemento primario (Ingresos) y dos dimensiones explcitas (productos y provincias).
76
4.7.6 Modelo Conceptual
xbrldt:hypercubeItem o xbrldt:dimensionItem. {all} {hypercube-dimension} {notAll} {hypercube-dimension}
Primary Elements son elementos definidos en taxonomas XBRL de tipo xbrli:item y no Arcos consecutivos son dos arcos en secuencia. En la especificacin se definen los siguientes: {hypercube-dimension} {dimension-domain} {dimension-domain} {domain-member}
77
4.7.6.1 Arcos all y notAll

Para restringir una serie de contextos para un elemento primario dado, dicho elemento puede estar asociado a cero o ms hipercubos. http://xbrl.org/int/dim/arcrole/all: arco cuyo origen es un primary item y destino un elemento hipercubo. El arco http://xbrl.org/int/dim/arcrole/notAll es la versin negada del anterior. Un conjunto de hipercubos se componen por la conjuncin de arcos all y notAll.
El elemento primario p_GrossProfit tiene asociados dos hipercubos. En una instancia, un contexto ser vlido con respecto al elemento primario slo si el pas que aparece en el escenario es miembro del hipercubo hc_CountriesHypercubeAll y no lo es de hc_CountriesHypercube Los arcos all y notAll requieren el atributo xbrldt:contextElement. Dicho atributo puede tomar dos valores, segmento y escenario. El atributo booleano opcional xbrldt:closed se utiliza para especificar si el hipercubo es cerrado (xbrldt:closed = true) con respecto al escenario o al segmento del contexto. Este atributo toma false como valor por defecto. Excluded.
78
4.7.6.2 Arcos hypercube - dimension

El arco http://xbrl.org/int/dim/arcrole/hypercube-dimension tiene como origen un elemento declarado como hipercubo y como destino un elemento definido como dimensin.
79
4.7.6.3 Dimensiones
Una dimensin es un elemento abstracto cuyo atributo substitutionGroup toma valor dimensionItem. Existen dos tipos de dimensiones: - Dimensiones typed - Dimensiones explcitas
4.7.6.3.1 Dimensiones typed
Una dimensin typed es un elemento dimensin cuyo dominio de miembros est definido en un elemento XML. La dimensin y el elemento XML se relacionan por el atributo xbrldt:typedDomainRef. definido el dominio de la dimensin. El atributo xbrldr:typedDomainRef es un xlink:href que apunta a un elemento XML donde est
4.7.6.3.2 Dimensiones explcitas

Una dimensin explcita es un elemento dimensin que tiene arcos dimension-domain que apuntan a cero o ms declaraciones domain-member. de los elementos XBRL como etiquetas en distintos idiomas, referencias, estructuras de presentacin Los miembros del dominio son elementos xbrli:item. Por tanto, heredan todas las propiedades
80
4.7.6.4 Arco dimension-domain

Tiene como origen la declaracin de una dimensin explcita y como destino la declaracin de miembros del dominio de la dimensin.
4.7.6.5 Arco domain-member

El atributo opcional xbrldt:usable se utiliza para evitar que ciertos miembros del dominio no aparezcan en un documento instanciado. Esto permite utilizar elementos cuya finalidad es organizar la jerarqua del dominio. Este atributo tiene como valor por defecto true. La utilizacin de este arco permite la creacin de conjuntos de miembros de dominio explcitos.
4.7.6.6 Valores por defecto

en dimensiones.
El arco http://xbrl.org/int/dim/arcrole/dimension-default permite definir valores por defecto
La relacin dimension-default especifica qu miembros del dominio actan por defecto para una dimensin. Dicho arco tiene como origen un elemento dimensin y como fuente el miembro a utilizar por defecto. Los valores por defecto no deben aparecer en el contexto de la instancia.
81
4.7.7 Instancias
Las taxonomas primarias definen conceptos cuyos valores son reportados en una instancia XBRL.
Cada valor reportado en la instancia tiene un contexto asociado. En dicho contexto est contenida la informacin dimensional. Dependiendo del valor del atributo xbrldt:contextElement, esta informacin se encontrar bien en el escenario, bien en el segmento:
Las dimensiones typed aparecen en la instancia de la siguiente manera:
82
4.8 Frmulas
4.8.1 Introduccin
Dentro del marco de intercambio de informacin en XBRL, se necesita que las aplicaciones que producen y consumen la informacin sean capaces de aplicar validaciones sobre los tipos y valores de los datos, tanto comprobaciones de consistencia de la informacin y sus posibles correcciones como proporcionar suficiente informacin a la aplicacin productora para detectar la gravedad de los errores encontrados.
Estas caractersticas que son comunes a cualquier aplicacin que utilice XBRL como formato de intercambio hace que uno de los objetivos del estndar XBRL haya sido siempre permitir a las aplicaciones consumir informacin XBRL sin importar la fuente de origen. La gestin de informacin para garantizar la calidad normalmente recomienda que las valida-
Las aplicaciones que intercambian informes electrnicos, en general, suelen aadir valores calculados y realizar pruebas sobre sus propias salidas antes de enviar la informacin al resto de aplicaciones. Estas aplicaciones derivan normalmente en temas de mantenimiento tanto de los datos como de las reglas de negocio (frmulas) asociadas a los criterios de validacin de los datos.
La validacin de los datos de entrada es un caso de uso para usar frmulas que detecten errores.
ciones se comprueben, anexen y corrijan tan arriba en el flujo de suministro de la informacin cadena.
se apliquen repetidamente a medida que la informacin viaja por los consumidores de la El lenguaje XBRL desde sus comienzos expresa no nicamente hechos producidos sino tam-
como sea posible. Se recomienda tambin que las mismas pruebas realizadas sobre los datos
bin las relaciones existentes entre los hechos y relaciones generales. Es decir, las taxonomas son una forma de documentar el significado de los conceptos reportados.
Dentro del primer planteamiento se han ilustrado deficiencias en los esquemas utilizados actualmente y las limitaciones que tiene actualmente el lenguaje dentro de los patrones tpicos de uso de XBRL para cubrir estas necesidades de expresar reglas de negocio y realizar validaciones avanzadas sobre los datos intercambiados.
De esta forma, otro caso de uso importante de las frmulas es que sirven para documentar las relaciones de clculo complejas entre los conceptos. De igual manera a como la linkbase de presentacin establece el lugar jerrquico donde debe aparecer presentado un concepto, la linkbase de frmulas indica la jerarqua dentro de una frmula en la que un concepto aparece. Esto es especialmente til a la hora de identificar aquellos conceptos que participan en el clculo de un ratio de anlisis, estando documentado en la linkbase.
83
Hasta la fecha la solucin de la mayor parte de procesamiento de estas reglas de negocio queda relegado bien en las aplicaciones (por ejemplo utilizando XQuery como lenguaje de consulta), bien en implementaciones propias de estas reglas en esquemas adicionales XML o bien en estructuras de diseo de taxonomas que tratan de exprimir al mximo posible la especificacin XBRL dada su flexibilidad:
Por todas estas necesidades nace la especificacin de frmulas XBRL como una ampliacin del lenguaje XBRL que permita la declaracin y publicacin de un conjunto de frmulas, para su procesamiento estandarizado.
84
El presente captulo pretende acercar a la problemtica de formulacin XBRL, desde su motivacin inicial en el reporting descrita en los requerimientos de negocio de las frmulas XBRL, hasta situar al lector en el marco actual de la especificacin. Para ello resumiremos la estructura del borrador interno de las especificaciones de frmulas y funciones, describiendo las distintas partes que la componen y daremos una orientacin de cada una de ellas. La especificacin de Frmulas XBRL nace tras la puesta en marcha de aplicaciones de intercambio de informacin en XBRL que demandan poder expresar reglas de negocio ms avanzadas que las sumas aritmticas actualmente soportadas en la linkbase de clculo.
4.8.2 Frmulas XBRL
A medida que estas aplicaciones producen y consumen informes XBRL, se detectan dos necesidades adicionales. Por un lado documentar en las taxonomas las relaciones de reglas de clculo matemtico avanzado existentes entre conceptos, y por otra parte declarar las relaciones que permitan realizar validaciones de consistencia de la informacin ms avanzadas en funcin de los datos de los informes. Pasamos a continuacin a describir ambos casos.
85
4.8.2.1 XBRL como forma de documentacin estndar de reglas de negocio
El lenguaje XBRL desde sus comienzos expresa hechos producidos y adems documenta las relaciones existentes entre los conceptos reportados. Mediante el mecanismo de linkbases se extiende el modelo de contenido de XML Schema disponiendo de categoras adicionales para expresar significado de los conceptos en forma de documentacin: Las taxonomas son una forma de documentar el significado de los conceptos reportados.
Esto es especialmente til a la hora de localizar dentro de un diccionario aquellos conceptos que participan en una frmula, por ejemplo, un ratio de anlisis financiero, a diferencia de aquellos que no participan.
De esta forma, establecer una documentacin entre conceptos que declare las relaciones de tipo formulado (clculo complejas) que existen entre los conceptos, ayudar, de igual manera que hacen el resto de linkbases, a dotar a los conceptos de mayor significado.
- Label Linkbase: Etiquetas o literales con una amplia variedad de posibilidades e idiomas. - Reference Linkbase: referencias de importancia a la hora de encontrar soporte legal y escrito de los conceptos. - Presentation Linkbase: Declaran relaciones tiles por las aplicaciones consumidoras a la hora de clasificar jerrquicamente los conceptos estableciendo los padres e hijos en un informe presentado. - Calculation Linkbase: Declaran relaciones de sumas y restas sobre los conceptos. - Definition Linkbase: Declaran relaciones ms semnticas entre los conceptos como pueden ser especializacin, similitud, pertenencia a un dominio de conocimiento, etc.
86
4.8.2.2 XBRL para validar la informacin intercambiada
Una parte fundamental de las aplicaciones que producen y consumen informacin XBRL es realizar comprobaciones de consistencia de los datos intercambiados y sus posibles correcciones, proporcionando a todas las aplicaciones que participan en la cadena de intercambio (reporting) de informacin, datos suficientes para poder detectar los posibles errores o inconsistencias encontradas en los valores de los informes producidos.
Para este propsito la asociacin XBRL Internacional, partiendo de los requerimientos de negocio identificados, est realizando una especificacin de frmulas que complemente la sintaxis actual de XBRL en su versin 2.1, y as poder definir reglas y validaciones de los datos de forma estandarizada e independiente de las aplicaciones que consuman los informes y poder automatizar ms el consumo de informes XBRL, garantizando la calidad de los datos.
87
4.8.3 Requerimientos de frmulas XBRL

Formula-Req-CR-2005-06-21.rtf
Los requerimientos de frmulas aqu comentados estn basados en el documento:
De forma general toda aplicacin que utilice frmulas XBRL debera ser capaz de cumplir los siguientes requerimientos:
Requerimientos de uso general Requerimientos de uso general
1. Comprobar la consistencia de los datos de los informes XBRL y emitir los fallos de una frmula, de forma similar al funcionamiento actual de XBRL 2.1 en la linkbase de clculo al reportar fallos de consistencia para los arcos de sumas summation-ite m . 2. Comprobar la consistencia de informes XBRL y proporcionar mensajes detallados de cada frmula que falle. En este caso, se considera que una salida general XML del procesador es lo ms apropiado para el subsiguiente procesamiento de errores por la aplicacin consumidora. 3. Crear un informe XBRL sin tuplas basado en otros documentos XBRL de entrada. En este caso, el procesador de frmulas es sensible de producir un informe XBRL vlido. Si las aplicaciones productoras verifican que su propia salida ser aceptada por aquellas aplicaciones
Requerimientos relacionados con l Requerimientos relacionados con linkbases
consumidoras ser posible obtener eficiencias significativas, sobre todo en un entorno distribuido como es Internet. 4. Transformar, adjuntar, o componer informes XBRL, incluyendo conceptos de tipo tupla donde el orden de creacin es relevante a diferencia del caso 3. 1. Un DTS (conjunto referenciable de taxonomas) puede incluir definiciones de frmulas. Es decir, debe ser posible definir un conjunto de frmulas de tal forma que puedan formar parte de uno o ms conjuntos referenciables de taxonomas (DTS s ) . 2. Las frmulas podran requerir el uso de diversos componentes de un DTS. Por ejemplo, las frmulas pueden hacer referencia a items y tuplas que estn definidos en las taxonomas de las que forman parte o sobre las que aplican. 3. Las frmulas podran ser agrupadas dentro de conjuntos o familias. 4. Una frmula, en general, define en s misma una relacin entre dos o ms hechos y por tanto un conjunto de frmulas debe usar el mismo atributo xlink:role que se emplea en la especificacin XBRL 2.1 para indicar mediante el role cul es la red de relaciones a utilizar. 5. Una frmula puede incluir documentacin, utilizando la sintaxis xlink de la especificacin XBRL 2.1 para asociar recursos (etiquetas y/o referencias) a las frmulas que se definan. 6. La declaracin de frmulas debera aparecer nicamente en linkbases asociadas con una taxonoma, de forma consistente al tratamiento de clculos, y no con la instancia. 88
A continuacin se describen los requerimientos de la semntica de procesamiento de frmulas relativa a las entradas y salidas XBRL.
Requerimientos relacionados con el procesamiento Requerimientos relacionados con el procesamiento
1. El resultado de aplicar frmulas a un informe que no es un documento XBRL vlido no est definido. 2. Los autores pueden escribir frmulas de tal manera que esperen recibir un documento XBRL vlido con respecto a un esquema taxonmico conocido. 3. La aplicacin de un conjunto de frmulas a un informe XBRL vlido debe resultar en un documento XML bien formado tanto de resultado positivo como de fallo. 4. Cualquier nmero de frmulas podran calcular el valor de cualquier tem. Las frmulas podran proporcionar distintas variantes para obtener un hecho. En la prctica la recomendacin es que los autores eviten escribir frmulas que se apliquen sobre el mismo conjunto de hechos para producir el mismo resultado, puesto que los hechos resultados podran aparecer duplicados o incluso contradictorios. 5. Toda frmula en un DTS debera ser procesada concurrentemente y sin excepcin sin tener en cuenta la prioridad.
Requerimientos relacionados con las expresiones: Requerimientos relacionados con las expresiones:
Identificaremos en este apartado tres tipos de expresiones:
1. Debera haber un nico lenguaje para las expresiones.
Binding expressions: expresiones que asocien argumentos a hechos; Precondition expressions: expresiones que puedan ejecutar una precondicin booleana de una frmula cuando sus argumentos se hayan encontrado; y Result expressions: para expresiones que alberguen el resultado de procesar una frmula. 3. El lenguaje de expresiones debera incluir operadores que puedan seleccionar cualquier nodo objetivo de asociacin de variables que exista en documento instanciado.
2. El lenguaje de expresiones debera ser reconocible por un programador de nivel medio 4. Las expresiones podran incluir constantes. 5. Las expresiones podran incluir operaciones matemticas.
Requerimientos de asociacin de hechos Requerimientos de asociacin de hechos
1. Toda frmula podra filtrar los hechos de entrada a los que aplica de acuerdo a las relaciones que existan entre los hechos de uno o ms contextos. 2. Los hechos asociados en una frmula podran tener diferentes contextos. 3. Las frmulas podran restringir los hechos sobre los que se aplican basndose en sus contextos. Este requerimiento tambin implica que el lenguaje de expresin proporcione una librera nativa para la manipulacin de funciones de fecha tales como los especificados en 89
XQuery y XPath [XQPFO]. 4. Las frmulas pueden restringir los hechos sobre los que aplican basndose en sus unidades y/o en su atributo de precisin o decimales segn sea el caso. 5. Debera ser capaz de aplicar filtros en la entrada de los hechos dependiendo de la estructura intrnseca de una tupla. En lugar de producir nicamente un resultado booleano, o indicar un fallo general como hemos descrito en la introduccin, un procesador de frmulas puede producir un aviso ms detallado o una explicacin de la ejecucin realizada o del problema encontrado.
Requerimientos de alertas Requerimientos de alertas
90
4.8.4 Especificacin de frmulas XBRL

Formula-Linkbase-Specification-IWD-2005-04-19.doc
En este apartado describiremos de forma resumida los trabajos del grupo XBRL Internacional basados en el documento interno del grupo: Dicho documento es el resultado tcnico del equipo de estandarizacin del grupo Specification dentro de XBRL International, realizado en base a los requerimientos anteriormente descritos para poder expresar mediante una linkbase de frmulas la declaracin de conceptos que expresen la problemtica asociada a clculos avanzados en el reporting XBRL.
Propsito Propsito
- Linkbase de frmulas para realizar validaciones complejas sobre los datos reportados en el documento instanciado. Dichas validaciones pueden ser reglas de negocio como un Anlisis de movimientos de Caja, por ejemplo. - Linkbase de frmulas para construir documentos instanciados complejos a partir de otros
datos reportados ms simples. Por ejemplo, reporting de conceptos de ratios a partir de valores financieros simples. - Linkbase de frmulas para resolver clculos entre valores reportados en distintos contextos. Puede ocurrir que segn el diseo de las taxonomas, exista una limitacin a la hora de realizar comprobaciones de clculo sobre los datos reportados si estos se encuentran englobados en diferentes contextos. Por ejemplo, en una taxonoma en la que hay una dimensin geogrfica y/o de unidades de negocio sobre una taxonoma primaria financiera, el poder comprobar que los totales y subtotales a lo largo de la dimensin se cumplen implica poder transponer los clculos del documento instanciado para aquellos contextos que se necesiten. - Documentar las relaciones existentes entre los conceptos a los que se aplican reglas de negocio.
La especificacin est organizada en dos grandes bloques, el modelo implcito de procesamiento, donde se dan las recomendaciones de explotacin de las frmulas por un procesador, y as facilitar la interoperabilidad, y la sintaxis de la linkbase propiamente dicha, donde se detallan los fragmentos XML y atributos de los elementos para expresar frmulas, de acuerdo a cada modelo de procesamiento.
Estructura Estructura
91
4.8.4.1 Modelo de procesamiento General
variables Toda frmula puede tener un conjunto de variables sobre las que utilizar datos que alimenten la frmula. Por ejemplo, para la frmula TotalActivo = ActivoMaterial + ActivoInmovilizado habra una variable para asignar los datos de ActivoMaterial y una variable para asignar los datos de ActivoInmovilizado.
En las frmulas se define el valor de expresin para indicar el resultado de evaluar la frmula. Generalmente el valor de expresin utiliza las variables como entradas para obtener el resultado, tras aplicarle una serie de operadores o funciones. Por ejemplo, para la frmula TotalActivo = ActivoMaterial + ActivoInmovilizado, los datos de ActivoMaterial seran
recurso Una frmula en XBRL est expresada como un recurso (xlink resource).
Puede ocurrir que el conjunto de variables de una frmula resulte vaco, cuando sea el caso en el que los valores que produce una frmula no se basen en ningn dato de entrada.
En general el motor de evaluacin de una frmula tendr adems en cuenta no slo los operfunciones relativas a las dimensiones adores de expresin sino tambin el resto de funciones relativas a las dimensiones (tanto estnDe igual forma a como se documentan los conceptos en la taxonoma XBRL, las frmulas pueden tener etiquetas y referencias (label, reference) para proporcionar literales legibles por las personas y referencias a literatura normativa acerca de las frmulas. dar como especficas de usuario). En el ejemplo anterior los valores de las variables son c-equal() y u-equal() si no se especifica lo contrario.
asignados a la variable $activoMaterial y los datos de ActivoInmovilizado seran asignados a la variable $activoInmovilizado. El valor de la expresin para la frmula sera $activoMaterial + $activoInmovilizado teniendo en cuenta el operador entre ambos (suma).
producir mensajes Las frmulas se pueden utilizar para producir mensajes de comprobacin de consistencia de los datos que se reciben en los documentos instanciados Las frmulas pueden tener mensajes de procesamiento asociados con ellas. Estos se utilizan para indicar una condicin de error o informes internos de procesamiento de la frmula.
resultado Como resultado de evaluar frmulas se puede indicar que se generen hechos XBRL. Este procreacin de hechos desde frmulas. ceso se denomina creacin de hechos desde frmulas.
Las frmulas son procesadas dentro del alcance de un conjunto de taxonomas descubiertas (Discoverable Taxonomy Set, DTS). El DTS proporciona toda la informacin de soporte necesaria para la ejecucin de la frmula (localizacin de los conceptos del esquema, tipo de dato, relaciones, etc.).
92
4.8.4.2 Sintaxis de Linkbase de frmulas
Para resumir la sintaxis sin entrar a detalle del borrador, podemos decir que se ha estructurado de forma similar a las dems linkbases de tipo jerrquico existiendo fragmentos XML (formulaLink) para englobar las frmulas, sobre los que se especifican elementos de tipo localizador (Locator), otros de tipo arco para establecer las relaciones (formulaArc), y otros de tipo recurso (formula type xl:resource), donde se especializan elementos y definen toda una serie de fragmentos XML de relevancia a la hora de realizar el procesamiento de frmulas como son las variables (Variables, itemVariable, tupleVariable), los resultados (instance) y los mensajes (message). Es importante en la ejecucin de una frmula la seleccin dentro del documento instanciado de los hechos que se asignan a una variable, teniendo en cuenta todas las caractersticas dimensionales del mismo (contexto, unidades, perodo temporal, otras dimensiones especficas), y tambin la utilizacin de filtros para los valores de los hechos. Para esta seleccin toda frmula y variable tienen un atributo (select) que sirve para indicar una expresin en el lenguaje XPath para la evaluacin de la variable en cuestin. En ambos casos la especificacin apunta a la utilizacin de fragmentos XML especficos dentro de una frmula, que definen las variables y los filtros.
Dentro del borrador interno de la especificacin, se detallan los elementos que definen la sintaxis de la linkbase de frmulas.
Dentro de la sintaxis de estos elementos se pueden declarar y utilizar funciones externas para su procesamiento, que realicen por ejemplo tareas de comprobacin de valores de periodos, de 93
unidades, o cualquier otra operacin. Veremos en el siguiente apartado un resumen sobre el estado de las funciones ms comunes que se estn estandarizando de cara a la interoperabilidad de procesadores, y mantienen la declaracin en la linkbase de frmulas independientemente de su implementacin. Puesto que el procesamiento de las frmulas aplica sobre documentos XBRL de entrada, es razonable pensar que un procesador de frmulas puede producir como resultado documentos XBRL de salida y tambin mensajes resultado de las comprobaciones de consistencia de estos datos de entrada.
Para ello la especificacin de frmulas incluye elementos en la linkbase que declaran el resultado tanto de los conceptos producidos como de los mensajes resultado.
94
95
96
4.8.5 Mdulo de Funciones XBRL

XF-REQ-IWD-2005-04-23.doc XF-IWD-2006-05-25.rtf xf-2006.xq
Los documentos de trabajo en los que se basa este apartado son:
Siendo este ltimo una librera con la implementacin de referencia en lenguaje XQuery de las funciones que se detallan en la especificacin XF.
Funciones. Requerimientos Funciones. Especificacin Funciones. Implementacin de referencia
La especificacin XBRL 2.1 ya describe varios predicados de igualdad (seccin 4.10) relativos a la identificacin de items y tuplas duplicadas, que sirven actualmente a los procesadores para utilizar como funciones reutilizables en su procesamiento, a la hora de comprobar la consistenjan sobre dos argumentos para devolver la evaluacin de valor verdadero o falso: cia de los informes XBRL. En concreto estos predicados son operadores comparativos que traba-
linkbase de frmulas descrita en el apartado anterior, se soporta en una serie de operaciones comunes. Por ejemplo, determinar el final del perodo de un hecho puede ser visto como una funcionalidad comn a ms de una frmula, por lo que sera razonable pensar en un conjunto de funciones para su implementacin y reutilizacin.
El procesamiento XBRL y en particular el requerido para implementar la funcionalidad de la
De la misma forma que podemos identificar estas funciones, la especificacin de funciones XF trabaja en extender a un conjunto variado de predicados de acuerdo con los requerimientos de procesamiento que aparecen tras la especificacin de frmulas. 97
4.8.5.1 Relacin de Funciones por categoras

Accessor Functions Items->Decimals and precision xfi:precision-of($item as xbrli:item) as xs:integer Items->Contexts and units xf :context of tem($ tem as xbr : tem) as xbr :context xfii:context--of--iitem($iitem as xbrllii:iitem) as xbrllii:context xf :un t of tem($ tem as xbr : tem) as xbr :un t xfii:uniit--of--iitem($iitem as xbrllii:iitem) as xbrllii:uniit
Se lista a continuacin la relacin de las funciones que se encuentran en los documentos clasificadas por categoras:
Items->Units xf :un t numerator($un t as xbr :un t) as xbr :measure* xfii:uniit--numerator($uniit as xbrllii:uniit) as xbrllii:measure* xf :un t denom nator($un t as xbr :un t) as xbr :measure* xfii:uniit--denomiinator($uniit as xbrllii:uniit) as xbrllii:measure* xf :measure name($measure as xbr :measure) as xs:QName xfii:measure--name($measure as xbrllii:measure) as xs:QName
Contexts Periods xf : s per od durat on($context as xbr :context) as xs:boo ean xfii:iis--periiod--duratiion($context as xbrllii:context) as xs:boollean xf : s per od forever($context as xbr :context) as xs:boo ean xfii:iis--periiod--forever($context as xbrllii:context) as xs:boollean xf : s per od nstant($context as xbr :context) as xs:boo ean xfii:iis--periiod--iinstant($context as xbrllii:context) as xs:boollean xf :per od start($context as xbr :context) as xs:dateT me xfii:periiod--start($context as xbrllii:context) as xs:dateTiime xf :per od end($context as xbr :context) as xs:dateT me xfii:periiod--end($context as xbrllii:context) as xs:dateTiime xf :per od nstant($context as xbr :context) as xs:dateT me xfii:periiod--iinstant($context as xbrllii:context) as xs:dateTiime
Segments and Entities xf : dent f er of ent ty($context as xbr :context) as xs:token xfii:iidentiifiier--of--entiity($context as xbrllii:context) as xs:token xf :scheme of dent f er($context as xbr :context) as xs:anyURI xfii:scheme--of--iidentiifiier($context as xbrllii:context) as xs:anyURI xf :segment content($context as xbr :context) as node()* xfii:segment--content($context as xbrllii:context) as node()* xf :scenar o content($context as xbr :context) as node()* xfii:scenariio--content($context as xbrllii:context) as node()*
Footnotes DTS Related Functions Facts and tuples Predicados Constructor Functions Creating items xf :create numer c tem($name as xs:QName, $va ue as xs:anyType, $context as xfii:create--numeriic--iitem($name as xs:QName, $vallue as xs:anyType, $context as xbr :context, $un t as xbr :un t, $prec s on as xs: nteger?, $dec ma s as xs: nteger?) xbrllii:context, $uniit as xbrllii:uniit, $preciisiion as xs:iinteger?, $deciimalls as xs:iinteger?) xf :create numer c tem($name as xs:QName, $va ue as xs:anyType, $context as xfii:create--numeriic--iitem($name as xs:QName, $vallue as xs:anyType, $context as xbr :context, $un t as xbr :un t, $prec s on as xs: nteger?, $dec ma s as xs: nteger?, xbrllii:context, $uniit as xbrllii:uniit, $preciisiion as xs:iinteger?, $deciimalls as xs:iinteger?, $attrs as attr bute()*) $attrs as attriibute()*) 98
Creating tuples xf :create tup e($name as xs:QName, $facts as (xbr : tem | xbr :tup e)*) as xbr :tup e xfii:create--tuplle($name as xs:QName, $facts as (xbrllii:iitem | xbrllii:tuplle)*) as xbrllii:tuplle xf :create tup e($name as xs:QName, $facts as (xbr : tem | xbr :tup e)*, $attrs as xfii:create--tuplle($name as xs:QName, $facts as (xbrllii:iitem | xbrllii:tuplle)*, $attrs as attr bute()*) as xbr :tup e attriibute()*) as xbrllii:tuplle xf :create wrapped tup e($name as xs:QName, $ nstance as xbr :xbr ) as xbr :xbr xfii:create--wrapped--tuplle($name as xs:QName, $iinstance as xbrllii:xbrll) as xbrllii:xbrll xf :create wrapped tup e($name as xs:QName, $ nstance as xbr :xbr , $attrs as attr b xfii:create--wrapped--tuplle($name as xs:QName, $iinstance as xbrllii:xbrll, $attrs as attriib-ute()*) as xbr :xbr ute()*) as xbrllii:xbrll Creating contexts xf :create start nstant context($context as xbr :context) as xbr :context xfii:create--start--iinstant--context($context as xbrllii:context) as xbrllii:context xf :create end nstant context($context as xbr :context) as xbr :context xfii:create--end--iinstant--context($context as xbrllii:context) as xbrllii:context xf :create durat on from nstant contexts($ eft as xbr :context, $r ght as xbr :context, xfii:create--duratiion--from--iinstant--contexts($lleft as xbrllii:context, $riight as xbrllii:context, $ d as xs:str ng) as xbr :contextxf :create forever context($ dent f er as xs:token, $iid as xs:striing) as xbrllii:contextxfii:create--forever--context($iidentiifiier as xs:token, $scheme as xs:anyURI, $segment as node()*, $scenar o as node()*, $ d as xs:str ng) as $scheme as xs:anyURI, $segment as node()*, $scenariio as node()*, $iid as xs:striing) as xbr :context xbrllii:context xf :create nstant context($ nstant as (xs:date | xs:dateT me), $ dent f er as xs:token, xfii:create--iinstant--context($iinstant as (xs:date | xs:dateTiime), $iidentiifiier as xs:token, $scheme as xs:anyURI, $segment as node()*, $scenar o as node()*, $ d as xs:str ng) as $scheme as xs:anyURI, $segment as node()*, $scenariio as node()*, $iid as xs:striing) as xbr :context xbrllii:context xf :create durat on context($startDate as (xs:date | xs:dateT me), $endDate as xfii:create--duratiion--context($startDate as (xs:date | xs:dateTiime), $endDate as (xs:date | xs:dateT me), $ dent f er as xs:token, $scheme as xs:anyURI, $segment as (xs:date | xs:dateTiime), $iidentiifiier as xs:token, $scheme as xs:anyURI, $segment as node()*, $scenar o as node()*, $ d as xs:str ng) as xbr :context node()*, $scenariio as node()*, $iid as xs:striing) as xbrllii:context Creating units xf :create product un t($un ts xbr :un t*, $ d xs:str ng) as xbr :un t xfii:create--product--uniit($uniits xbrllii:uniit*, $iid xs:striing) as xbrllii:uniit xf :create nverse un t($un t xbr :un t, $ d as xs:str ng) as xbr :un t xfii:create--iinverse--uniit($uniit xbrllii:uniit, $iid as xs:striing) as xbrllii:uniit xf :create un t($numerator as xs:QName+, $denom nator as xs:QName*, $ d as xfii:create--uniit($numerator as xs:QName+, $denomiinator as xs:QName*, $iid as xs:str ng) as xbr :un t xs:striing) as xbrllii:uniit
xfi:create-non-numeric-item($name as xs:QName, $value as xs:anyType, $context as xfi:create-non-numeric-item($name as xs:QName, $value as xs:anyType, $context as xbrli:context) xbrli:context) xfi:create-non-numeric-item($name as xs:QName, $value as xs:anyType, $context as xfi:create-non-numeric-item($name as xs:QName, $value as xs:anyType, $context as xbrli:context, $attrs as attribute()*) xbrli:context, $attrs as attribute()*) xfi:create-nil-item($name as xs:QName, $context as xbrli:context, $unit as xbrli:unit?) xfi:create-nil-item($name as xs:QName, $context as xbrli:context, $unit as xbrli:unit?) xfi:create-nil-item($name as xs:QName, $context as xbrli:context, $unit as xbrli:unit?, xfi:create-nil-item($name as xs:QName, $context as xbrli:context, $unit as xbrli:unit?, $attrs as attribute()*) $attrs as attribute()*)
Creating instances xf :create schema ref($ ocat on as xs:anyURI) as xbr :schemaRef xfll:create--schema--ref($llocatiion as xs:anyURI) as xbrllll:schemaRef xf :create nkbase ref($ ocat on as xs:anyURI) as xbr : nkbaseRef xfll:create--lliinkbase--ref($llocatiion as xs:anyURI) as xbrllll:lliinkbaseRef xf :create nkbase ref($ ocat on as xs:anyURI, $ro e as xs:str ng) as xbr : nkbaseRef xfll:create--lliinkbase--ref($llocatiion as xs:anyURI, $rolle as xs:striing) as xbrllll:lliinkbaseRef xf :merge nstances($xbr s as xbr :xbr *) as xbr :xbr xfii:merge--iinstances($xbrlls as xbrllii:xbrll*) as xbrllii:xbrll xf :create nstance($refs as x :s mp e+, $facts as (xbr : tem | xbr :tup e)*, $contexts as xfii:create--iinstance($refs as xll:siimplle+, $facts as (xbrllii:iitem | xbrllii:tuplle)*, $contexts as xbr :context*, $un ts as xbr :un t*) xbrllii:context*, $uniits as xbrllii:uniit*) Taxonomy Functions 99
4.9 Versionado
El propsito del versionado de taxonomas consiste en permitir la comparacin, el anlisis y la correcta identificacin de los datos que han cambiado en los documentos XBRL que forman las taxonomas. Para ello, es necesario documentar correctamente la informacin sobre las diferencias existentes entre ellas. Los usuarios de la taxonoma que automatizan sus procesos de reporte son afectados por los cambios de versin, en el sentido de que podran necesitar efectuar cambios en sus sistemas internos. La documentacin de los cambios en la taxonoma permite valorar los cambios realizados entre versiones y saber qu elementos cambian y/o desaparecen Respecto al versionado se consideran buenas prcticas:
- Cambios en la normativa legal que origina el reporting: circulares, normativas contables, etc. - En el caso de ser una taxonoma extendida de otra, un cambio en la taxonoma superior, puede originar un cambio. - Cambios debidos a incidencias correctivas originadas por el uso tecnolgico de las taxonomas. - Cambios en la normativas de Buenas Prcticas sobre las que se soporta (FRTA, ISO, etc.). - Cambio en las versiones de la especificacin XBRL y de las especificaciones XML de soporte (XLink, XML Schema, etc.).
Las taxonomas pueden cambiar a lo largo del tiempo debido a diferentes factores, entre ellos:
- Documentar los cambios realizados entre dos versiones distintas de la taxonoma, identificando cada cambio o revisin con un cdigo unvoco al que poder hacer referencia en otros documentos. (Listas de Control de Cambios). - Cambiar el namespace con cada versin nueva de una taxonoma. El namespace es el identificador biunvoco de la versin de la taxonoma. Dos taxonomas de dos versiones diferentes NO DEBEN tener el mismo namespace. - Identificar los cambios en elementos del diccionario de datos de la taxonoma con cdigos como copiado, eliminado, renombrado, movido, etc. en la hoja de control de cambios. - Describir la fecha de lanzamiento de la taxonoma en el nombre de los ficheros de los documentos, y adems en identificador de los namespaces. - Identificar la versin en la cabecera de los documentos XML de la taxonoma: diccionario de datos y linkbases referenciados. - Identificar exactamente qu elementos de los documentos de la taxonoma: linkbases y diccionario de datos han sido afectados por los cambios de versiones. - Especificar sobre qu versiones de normativas (FRTA Candidate Recomentation 5, FRIS, etc.) y especificaciones (XBRL 2.1., Xlink 1.0) est diseada la nueva versin. 100
- En el caso de organismos regulatorios, poner a disposicin de los usuarios un sitio pblico con un repositorio de las taxonomas donde se pueda consultar la vigencia de la versin de la taxonoma y disponer un repositorio de todos las taxonomas emitidas. - Asegurar la estabilidad, sin variaciones, de la taxonoma durante un periodo aconsejado de un ejercicio.
101
A la hora de implantar XBRL en una organizacin, el mercado ofrece muchas soluciones y herramientas especficas para el tratamiento del lenguaje XBRL, adems de las ya disponibles para trabajar con tecnologas XML. Estas herramientas pueden variar en funcin del nivel de la solucin XBRL a implantar, y por tanto del uso o funcionalidad requerida. Por ejemplo: - Herramientas especficas para la edicin de taxonomas, generacin de instancias, etc. - Herramienta de desarrollo de aplicaciones a medida para el procesamiento de documentos XBRL. - Plataforma global de reporting financiero XBRL para la generacin, administracin, validacin, gestin y almacenamiento de documentos XBRL, as como la propia definicin y generacin de los informes. Algunos ejemplos de los principales productores de herramientas XBRL:
5 5 Productos y Servicios
102
Batavia XBRL Products son una serie de productos para XBRL basados en Java. Editor online de instancias, API Java para desarrollo sobre XBRL y la herramienta ReportLink de integracin XBRL. Ha desarrollado Flexible v2.1-compliant XBRL processor y otros productos asociados como XBRL Web Express (valida online instancias), XBRL Office Express para importar, crear, validar y exportar instancias XBRL a MS Excel. Y XMetal Customization para hacer reporting financiero usando XBRL. Dispone de productos y servicios para implementar XBRL, como True North para procesamiento y validacin XBRL. Tambin dispone de un API para desarrollo en XBRL. Edicom Bussines Integrator XBRL Edition. Una herramienta que cubre ntegramente todo el proceso transaccional: EBI, un completo EAI que se ocupar de implementar y gestionar el bus de datos efectuando las transformaciones necesarias (Mapping) as como la validacin de instancias, un potente administrador de comunicaciones: gestin de interlocutores, seguridad (firma y encriptacin), histricos y un editor de taxonomas con soporte a linkbases.
Batavia www.batavia-xbrl.com Batavia www.batavia-xbrl.com
Blast Radius www.blastradius.com Blast Radius www.blastradius.com
DecisionSoft www.decisionsoft.com DecisionSoft www.decisionsoft.com Edicom www.edicom.es/xbrl Edicom www.edicom.es/xbrl
Ofrece amplia gama de herramientas para crear, editar taxonomas e instancias, procesamiento de XBRL, validacin e integracin XBRL. XiRUTE ToolSet ofrece un API para desarrollar con el estndar XBRL DOM con la misma interfaz que el W3C DOM.
Fujitsu software fujitsu.com/en/interstage-xwand/activity/xbrltools/index.html Fujitsu software fujitsu.com/en/interstage-xwand/activity/xbrltools/index.html Hitachi www.hitachi.co.jp/XBRL Hitachi www.hitachi.co.jp/XBRL
Microsoft www.microsoft.com/latam/office/solutions/xbrl/overview.mspx Microsoft www.microsoft.com/latam/office/solutions/xbrl/overview.mspx Rivet Software www.rivetsoftware.com Rivet Software www.rivetsoftware.com
Word 2003 y Microsoft Office Excel 2003 para crear y analizar documentos en formato XBRL. Dragon Tag 1.0 es una herramienta para crear fcilmente informes XBRL a partir de documentos MS Word y Excel.
Ofrece un prototipo de Herramienta de Office para XBRL que puede utilizar Microsoft Office
Ofrece soluciones como Next Generation XBRL Productivity Tools, para creacin, anlisis y procesamiento de taxonomas. Ofrece tambin soluciones de integracin XBRL y reporting financiero.
Semansys Technologies BV www.semansys.com Semansys Technologies BV www.semansys.com
103
Ofrece soluciones para reporting, validacin y anlisis sobre XBRL. Su framework de desarrollo Digital Reporting Platform permite desarrollar proyectos de reporting XBRL. Ofrece soluciones para reporting, validacin y anlisis sobre XBRL. Automator XBRL Professional permite crear taxonomas, UBS es un servidor web para integracin XBRL junto con XBRL Converter, y tambin ofrece un API para desarrollar sobre XBRL llamado XBRL ToolKit.
Software AG Espaa www.softwareag.com/es Software AG Espaa www.softwareag.com/es Ubmatrix www.ubmatrix.com Ubmatrix www.ubmatrix.com
En el siguiente listado se pueden apreciar algunas de las funcionalidades que soportan las herramientas XBRL. Se incluye una muestra de productos que ofrece el mercado.
Funcionalidad a evaluar: Funcionalidad a evaluar:
Crear y editar instancias XBRL: permite crear y editar instancias XBRL que corresponden a una taxonoma. informacin en ella y recogerla. Extraccin de informacin de las instancias XBRL: permite procesar la instancia para buscar
Crear y editar taxonomas: ayuda a la visualizacin, creacin y modificacin de taxonomas.
Validacin de instancias XBRL: validacin sintctica conforme a especificacin XBRL (conformidad mnima) y/o semntica conforme a la taxonoma (completa). Validacin de taxonomas: validacin sintctica de la taxonoma.
Representacin en pantalla de XBRL (XML-HTML): es capaz de mostrar un informe HTML conforme a las linkbases de presentacin.
Conversin a versin 2.0 -> 2.1: capaz de convertir un documento de la especificacin XBRL 2.0 a la 2.1.
Control de versin integrado: mantiene una historia de los documentos XBRL usados, y de los cambios realizados en ellos. Gestin de un repositorio interno: capacidad para almacenar documentos XBRL en un repositorio. Integracin Excel: capacidad para exportar/importar a MS Excel. Comparacin entre taxonomas: permite ver diferencias entre una taxonoma y otra.
104
6 Formacin
Tecnolgicamente XBRL hace uso intensivo de las especificaciones que sobre XML se han ido construyendo. En los captulos 3 y 4 del presente libro se han detallado conceptos bsicos sobre XML y XBRL. En este captulo slo glosaremos la estructura de conocimientos que de XML y las especificaciones accesorias se debe poseer para afrontar un proyecto XBRL, y la pauta bsica de adquisicin de estos conocimientos.
XBRL Espaa ha elaborado un documento especfico de Formacin y Buenas Prcticas en XBRL, que se encuentra accesible en la web de XBRL Espaa, en el que se tratan ampliamente las necesidades de formacin en un proyecto XBRL. Algunas empresas que ofrecen servicios de formacin XBRL: Azertia http://www.azertia.com Edicom http://www.edicom.es/xbrl Fujitsu http://www.fujitsu.com/es/services/sectors/bank/solutionsbank/solop.html PricewaterhouseCoopers http://www.pwc.com/xbrl Software AG http://www.softwareag.es/institute
105
6.1Tecnologas
XML Schema, se puede encontrar en la sede de la organizacin del W3C, (http://www.w3.org/XML/Schema). De acuerdo a la informacin que la sede ofrece sobre la especificacin, XML Schema permite expresar vocabularios, definir estructuras, contenido y semnticas para documentos XML. XML Schema fue aprobado como recomendacin del W3C el 2 de mayo de 2001. La especificacin se estructura en dos documentos:
XBRL ha utilizado la especificacin XML Schema para poder construir la estructura de definicin de elementos, que compone la taxonoma.
XML Schema Part 1: XML Schema Part 1: Structures contiene el ncleo de la especificacin, describe los mecanistodos los tipos de elementos que son utilizables por la especificacin, es accesible en idioma ingls en el vnculo http://www.w3.org/TR/xmlschema-2/ .
mos que XML Schema provee para poder representar estructuras XML, se puede acceder a l, en idioma ingls, en el siguiente vnculo http://www.w3.org/TR/xmlschema-1/ . XML Schema Part 2: XML Schema Part 2: Datatypes complementa el documento anterior con la definicin de La especificacin de espacios de nombres (en adelante namespaces) se utiliza en tecnologas XML, para resolver los problemas de colisin en los documentos XML, documentos que contienen elementos con el mismo nombre pero diferente significado. XBRL la utiliza ampliamente. Se puede consultar en: http://www.w3.org/TR/REC-xml-names/ . XBRL utiliza la especificacin XLink para permitir las relaciones entre los elementos definidos
en el Esquema y su utilizacin como recurso en las Linkbases XBRL. La especificacin XLink se encuentra accesible en W3C, http://www.w3.org/XML/Linking . XPath es una especificacin del W3C, que permite ser utilizado en XBRL, para procesar documentos XML obteniendo partes del documento. Es un lenguaje de consulta. La especificacin se encuentra en http://www.w3.org/TR/xpath. XPath es una tecnologa candidata a ser usada en la Linkbase de frmulas.
XQuery es una especificacin con status de Working Draft, que se utiliza para implementar intrpretes de lenguajes de consulta a los documentos XML. Se puede localizar en http://www.w3.org/TR/2005/WD-xquery-20050404/ .
106
6.2 Tecnologas de Manipulacin XML
Los documentos XML necesitan ser manipulados para obtener la informacin que contienen. XML como especificacin contiene informacin suficiente como para construir aplicaciones informticas que puedan procesar la informacin contenida en ellos. Estas piezas de software se conocen como Intrpretes o Parsers. Los intrpretes debern comprobar que los documentos XML estn bien formados, de acuerdo a la especificacin. Y, si poseen informacin sobre su esquema XML, podrn ser validados.
Existen dos tipos de intrpretes, Intrpretes DOM e Intrpretes SAX. A continuacin se describen ambos brevemente:
Intrpretes SAX (Simple API for XML) Los intrpretes SAX, utilizan mecanismos de interpretacin basados en eventos. El intrprete Ms informacin sobre SAX en http://www.saxproject.org/. transfiriendo el control a la aplicacin.
Intrpretes DOM (Document Object Model) Los intrpretes DOM transforman el documento XML, que est en forma textual en una estructura de rbol. Esta estructura es jerrquica y los intrpretes proveen de mecanismos (mtodos) para navegar por el rbol. DOM es una especificacin que se puede recuperar de la sede del W3C http://www.w3.org/DOM/. SAX informa a las aplicaciones que lo utilizan de la ocurrencia de un determinado evento,
Existen intrpretes en todas las tecnologas de la informacin, Java, .Net, PHP, etc. Entre ellos los siguientes: - Xerces (Apache). - XJ (Data Channel). - MSXML (Microsoft).
Las tecnologas XML tambin poseen manipuladores que permiten la transformacin de un documento XML a diferentes formatos. Esta tecnologa es XSL. XSL es un lenguaje de comandos XML que un intrprete, el procesador de hojas de estilo, utiliza para procesar el documento XML. El resultado de este proceso puede ser otro documento XML o un tipo de archivo que es capaz de ser interpretado por otras aplicaciones, PDF, CSV, XHTML, etc. Estas tecnologas se pueden utilizar en la representacin de instancias XBRL.
Los parsers XBRL pueden utilizar estos modelos de interpretacin, aadiendo a las capacidades de los mismos las necesidades especficas de XBRL.
107
6.3 Esquema de Aprendizaje
A continuacin se describe un esquema de Lnea de Aprendizaje en XBRL.
108
7 Material de referencia y ejemplos

7.1 Esquema general de casos de uso e implementacin de un sistema XBRL siguiendo una arquitectura orientada a servicios
Este ejemplo muestra una serie de roles y patrones de uso e implementacin de una arquitectura XBRL, que ha sido determinada con objeto de posibilitar una infraestructura automatizada de recepcin de informes XBRL, definicin y distribucin de taxonomas y transformacin de informes XBRL a formatos especficos de aplicaciones informticas de back office. Sin nimo de realizar un trabajo exhaustivo dada la escasa experiencia en el uso de XBRL y con objeto de delimitar el mbito de actuacin se empez por determinar los casos y roles de uso de XBRL implicados en el sistema y que, al margen de roles menores, fueron: - Definicin de taxonomas XBRL. - Construccin de taxonomas XBRL. - Emisin de informes XBRL. - Emisin automatizada. - Emisin manual. - Recepcin de informes XBRL. - Recepcin automatizada. - Recepcin manual. - Anlisis de informacin.
La experiencia ha demostrado que, si bien para el trabajo de anlisis de datos se requieren conocimientos profundos del negocio, la implementacin en una terminologa XBRL debe contar con especialistas en anlisis de sistemas de informacin y el uso de herramientas propias del desarrollo de software: Anlisis y normalizacin de datos. Definicin del modelo de datos. Requerimientos versionados de taxonomas en desarrollo. Requerimientos de trabajo en grupo.
Los dos primeros roles son realizados por usuarios que analizan los requerimientos de negocio y definen las necesidades de intercambio de informacin, la normalizacin de la misma y la modelo de datos implementacin de esos requerimientos en un modelado XBRL, en definitiva el modelo de datos y su mp ementac n. y su iimpllementaciin.
109
En sentido estricto, estos dos primeros roles son los Diseadores XBRL y necesitan herramientas propias de desarrolladores de software, adaptadas, en algunos casos, a la tecnologa XBRL.
- Pruebas y validacin de taxonomas en desarrollo. - Requerimientos de entornos de desarrollo, preproduccin y produccin.
El resto de roles estn directamente relacionados con el tratamiento de la informacin operativa, tanto desde el punto de vista de los emisores de este tipo de informacin como de los receptores y analistas de la misma y son los que de forma ms propia pueden ser llamados Usuarios XBRL .
A partir de la determinacin de intervinientes en el sistema de informacin se definieron los servicios necesarios y las caractersticas de su implementacin: - Arquitectura informtica orientada a servicios. - El sistema ha de ser altamente escalable y extensible ya que el volumen de la informacin intercambiada, almacenada y con necesidades de anlisis es potencialmente enorme. - Aislamiento y encapsulacin de las especificidades de la tecnologa XBRL para las aplicaciones informticas de back end.
- Independencia de la especificacin XBRL con objeto de que modificaciones en la misma no impacten en los sistemas informticos diseados. - Independencia de canales de entrada y salida de informes XBRL con la propia infraestructura XBRL. - Incorporacin de los servicios XBRL en la arquitectura general de servicios de infraestrucSiguiendo estas directrices se definieron una serie de servicios centrales y se dot de herramientas especializadas a los intervinientes en el sistema que permitiera de forma cmoda la consecucin de anlisis y generacin de las taxonomas. tura generales.
Los servicios centrales se dirigieron principalmente a la automatizacin en el tratamiento de informes XBRL en sus diversas facetas (generacin de informes XBRL, validacin de informes XBRL, emisin y recepcin segura de la informacin cifrado y descifrado de la informacin-, almacenamiento de informes XBRL). Los servicios desarrollados han sido: - Servicios de taxonomas. - Desarrollo de taxonomas. - Publicacin y suscripcin de taxonomas. - Servicios de prevalidacin y validacin de informes XBRL. 110
Igualmente y teniendo en cuenta la bisoez de la tecnologa y el requerimiento poltico del proyecto de ser un acelerador y aglutinante en la implementacin de la misma, se decidi externalizar parte de los servicios para su uso por los terceros emisores de informacin, permitindoles el acceso a los servicios de prevalidacin, validacin y transformacin de informes XBRL sin que incurrieran en las inversiones que esta tecnologa requiere. El siguiente diagrama muestra la arquitectura de alto nivel de los servicios centrales del sistema.
- Servicios de transformacin de informes XBRL a formatos amigables. - Por role, idioma - A fichero plano, a formatos especficos de back office... - Servicios generales de infraestructura. - Seguridad (autenticacin, firma electrnica, cifrado y descifrado). - Servicios de orquestacin de procesos e integracin de aplicaciones. - Informes de usuario (HTML, PDF, Excel). - Servicios de persistencia de datos (Bases de Datos de taxonomas) y DTSs (Base de Datos de XBRL Reports). - Utilizacin del resto de servicios generales de la instalacin.
111
LIBRO BLANCO
GRUPO DE TRABAJO DE TECNOLOGA 2006

Libro - Blanco XBRL

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Libro - Blanco XBRL

Uploaded by

Copyright:

Available Formats

NDICE

Prlogo Prlogo a la primera edicin

4 XBRL. Conceptos y recomendaciones 4 XBRL. Conceptos y recomendaciones

5 Productos y Servicios 5 Productos y Servicios 6 Formacin 6 Formacin

106 106 106 106

7 Material de referencia y ejemplos 7 Material de referencia y ejemplos

Enrique Muoz Garca

Prlogo a la primera edicin

Accountants in England and Wales).

CICA (Canadian Institute of Chartered Accountants) o el ICAEW (Institute of Chartered

(Internacional Accounting Standards Board), el IMA (Institute of Management Accountants), el

Huelva, Junio de 2005

Enrique Bonsn Ponte

Enrique Bonsn Ponte

2 2 Objetivos del documento

3.1 XML como lenguaje universal

3 3 XML y XBRL. Conceptos bsicos

3.2 Necesidades de un lenguaje estndar de reporting empresarial

3.3 XBRL como un lenguaje de etiquetado expresando reglas

4.1 Especificacin XBRL versin 2.1

4 4 XBRL. Conceptos y recomendaciones

4.1.1 Descripcin de la especificacin XBRL versin 2.1

lizados en el resto del documento.

<inmovilizado>1000</inmovilizado> <totalActivo>1000000</totalActivo> <capitalSocial>2000</capitalSocial> <totalPasivo>1000000</totalPasivo> </xbrl>

<xbrl> <schemaRef xlink:href=taxonomia.xsd/>

4.1.2 Informes XBRL

4.1.2.1Elementos simples y complejos: Items y tuplas

Notas aclaratorias en XBRL

<ci:cuentasACobrar id=item1 unitRef=Euro contextRef=c1 precision=INF>455680</ ci:cuentasACobrar>

4.1.3 Taxonomas XBRL

Una taxonoma contiene:

El captulo 5 de la especificacin se dedica por completo a explicar las taxonomas XBRL.

4.1.3.1 Definicin de conceptos en las taxonomas XBRL

<element id=tax_CajaYBancos name=CajaYBancos xbrli:periodType=insta n t type=xbrli:monetaryItemType substitutionGroup=xbrli:item nillable=true/>

<tax:CajaYBancos unitRef=u1 contextRef=c1 precision=7>1523554</tax:CajaYBancos>

4.1.3.2 Linkbase de etiquetas

4.1.3.3 Linkbase de referencias

una empresa y la normativa internacional de contabilidad.

4.1.3.4 Linkbase de presentacin

En XBRL esto se debe modelar de la siguiente manera:

El concepto Reservas ser de tipo instant.

El concepto Incrementos o disminuciones de las reservas ser de tipo duration.

4.1.3.5 Linkbase de clculo

4.1.3.6 Linkbase de definicin

Especificacin XBRL 2.1:

4.2.1 Almacenamiento XML/XBRL

para XML no puedan ser utilizadas con XBRL.

Productos / Herramientas: Productos / Herramientas:

Almacenamiento en Bases de Datos Relacionales

4.2.1.2.1 Transformacin de contenidos XBRL a modelos relacionales

Productos / Herramientas: Productos / Herramientas:

O - Oracle XML DB (http://www.oracle.com)

4.2.1.2.2 Almacenamiento de documentos ntegros en columnas de tipo XML

Productos / Herramientas: Productos / Herramientas:

- SQL Server 2005 - SQL Server 2005 (http://www.microsoft.com).

Almacenamiento en Bases de Datos XML Nativas

BBDD XML Nativas:

Poet (http://www.poet.com) Jasmine (http://www.cai.com) ObjectStore (http://www.odi.com) GemStone (http://www.gemstone.com)

Como ejemplos de SGBDOO existentes en el mercado:

Productos / Herramientas: Productos / Herramientas:

- Tamino XML Server - Tamino XML Server (versin 4.2) (http://www.softwareag.com).

Otras de las caractersticas destacables de este producto son:

- Xindice (versin 1.1.b4) - Xindice (versin 1.1.b4) - (http://xml.apache.org).