PLATAFORMA DE INTEROPERABILIDAD, PDI INTRANET GUBERNAMENTAL República de Colombia - Derechos Reservados

Transcripción

2 FORMATO PRELIMINAR AL DOCUMENTO Título: Fecha elaboración aaaa-mm-dd: Sumario: GEL-XML, LENGUAJE DE INTERCAMBIO DE INFORMACIÓN: GUIA DE CREACIÓN DE ESQUEMAS XML Presentar un conjunto de guías básicas para el desarrollo de esquemas XML dentro de la especificación GEL-XML Palabras Claves: Esquemas, Schema, GEL XML Formato: DOC Lenguaje: Español Fecha de publicación Fecha de modificación aaaa-mm-dd: aaaa-mm-dd: Dependencia: Ministerio de comunicaciones: Programa Agenda de Conectividad Proyecto Intranet Gubernamental. Código: Versión: 3.9 Estado: Publicado Categoría: Estándares Autor (es): Equipo GEL-XML: Departamento Administrativo Nacional de Estadística, DANE. Departamento Nacional de Planeación, DNP. Ministerio de Comunicaciones: Programa Agenda De Conectividad. Ministerio de Hacienda y Crédito Público: Proyecto de Interoperabilidad SIIF Nación. Ministerio de la Protección Social, MPS: Programa de Apoyo a la Reforma en Salud, PARS. Informática Siglo 21 ISL S.A Revisó: Equipo GEL-XML Aprobó: Información Adicional: Ubicación: Equipo GEL-XML El archivo magnético asociado al documento está localizado en Página 2 de 85

3 CONTROL DE CAMBIOS VERSIÓN FECHA RESPONSABLE NATURALEZA Equipo HP-MS Versión Inicial del documento 1.0a Eliécer Vanegas Ajustes respecto a: Murcia/ Grupo de Cambios en el formato de presentación del documento trabajo GEL-XML Equipo GEL-XML Complemento de la Guía de Creación de esquemas: - Ajustes ortográficos. - Adición de ejemplos. - Ajustes sobre versionamiento. - Inclusión de ejemplos. - Inclusión regla de usos. - Ajustes de redacción. - Definición de metadatos a incluir en los esquemas. - Ajustes de formato del documento Equipo GEL-XML - Ajustes sobre etiquetas ref e import y trabajo futuro Equipo GEL XML - Inclusión ejemplo uso de etiqueta import Equipo GEL-XML - Ajustes generales de ortografía - Inclusión para la especificación de adaptadores Equipo GEL-XML - Revisión sección control de cambios - Ajustes en la sección de adaptadores - Revisión sintaxis ejemplos XML César Ariza - Adición de ejemplos en adaptadores - Correcciones Generales César Ariza - Ajustes sobre adaptadores - Recomendaciones sobre el inclusión (import) para evitar referencias circulares - Ajustes explicación al patrón Venetian Blind. - Correcciones ortográficas César Ariza - Ajustes en los adaptadores - Adición de guías para la inclusión de elementos de datos en bibliotecas. - Adición de guías para la inclusión de elementos de datos de estándares externos César Ariza - Ajuste en ejemplos de inclusión de elementos de dato en bibliotecas César Ariza - Ajuste ejemplo sección César Ariza - Ajuste ejemplo sección 6.7 espacios de nombres Página 3 de 85

4 TABLA DE CONTENIDO DERECHOS DE AUTOR... 9 CRÉDITOS INTRODUCCIÓN AUDIENCIA REQUISITOS CONCEPTOS BÁSICOS ESTRUCTURA Y TERMINOLOGÍA ESTRUCTURA TERMINOLOGÍA GUÍAS PARA LA GENERACIÓN DE ESQUEMAS GEL-XML LINEAMIENTOS INÍCIALES Lenguaje para la especificación de los esquemas Detalles del diseño en XML Patrones del diseño de esquemas XML Complejidad de los esquemas Modelar datos, no formularios Nombre de los archivos que contienen los esquemas Reutilización de elementos VERSIONAMIENTO Políticas de versionamiento Mecanismo propuesto para el manejo de versiones Reflejar los números de la versión en el esquema Cambios que pueden ser incorporados a una versión menor Cambios que implican un cambio de versión mayor Página 4 de 85

5 6.2.6 Reflejar los números de las versiones menores Reflejar los números de la versión en las instancias Las reglas sobre la versión mayor y menor que aplican a esquemas de listas de valores conocidos Las reglas de compatibilidad de versiones RELATIVAS A LOS ELEMENTOS Modelado de los elementos Data Types vs. Declaración de Elementos Atributos vs. Elementos OTRAS RECOMENDACIONES Referencias absolutas y relativas Uso de instancias de ejemplo Esquemas de mensajes Definición de conjuntos de valores conocidos REPRESENTANDO CONDICIONES ALTERNAS COMENTARIOS EN LOS ESQUEMAS MECANISMOS DE REUTILIZACIÓN GUÍAS DE COMPONENTES DE ESQUEMAS GEL-XML CONVENCIONES DE NOMBRES USO DE HERENCIA (EXTENSIÓN Y RESTRICCIÓN) USO DE LOS ATRIBUTOS DEFAULT (POR DEFECTO) Y FIXED (FIJO) CONTENIDO DE LOS ELEMENTOS ATRIBUTOS LOCALES Y GLOBALES TEXTO VS. CÓDIGOS CONTENIDO MIXTO EN LOS ELEMENTOS USO DE [CDATA] USO DE <ANY>, <ANYATTRIBUTE> ALMACENAMIENTO DE LOS ARCHIVOS ATRIBUTO TARGETNAMESPACE USO DE PATRONES DE VALIDACIÓN DE DATOS EN LOS ESQUEMAS Página 5 de 85

6 8 LAS BIBLIOTECAS COMUNES PROBLEMAS EN EL DISEÑO DE BIBLIOTECAS COMUNES Sobre inclusión Carencia de un ciclo de vida separado ESTRUCTURACIÓN DE LOS ESQUEMAS COMPARTIR COMPONENTES PADRE USO COMÚN CON OTROS COMPONENTES PROBABILIDAD DE CAMBIO ÁMBITO / INSTANCIA ELEMENTOS LOCALES CON PREFIJOS ESPACIOS DE NOMBRES Y VERSIONAMIENTO DEFINICIONES COMUNES Y ESPACIOS DE NOMBRES LOS ESPACIOS DE NOMBRES GUÍAS PARA USO DE METADATOS EN GEL-XML ESQUEMAS Y METADATOS VERSIONAMIENTO DE LOS ESQUEMAS MEDIANTE EL ATRIBUTO VERSION INDICANDO LA VERSIÓN DEL ESQUEMA EN LAS INSTANCIAS EL ATRIBUTO ID EN EL ELEMENTO ESQUEMA ADAPTADORES ESPECIFICACIÓN DE ADAPTADORES Inclusión de los adaptadores en la documentación de los esquemas FACTIBILIDAD EN LA CREACIÓN DE ADAPTADORES SOFTWARE PARA LA EJECUCIÓN DE TRANSFORMACIONES TRABAJO FUTURO REFERENCIAS APÉNDICES APÉNDICE A: PALABRAS CLAVES A UTILIZAR PARA INDICAR NIVELES DE REQUERIMIENTO (RFC 2119) Página 6 de 85

7 13.2 APÉNDICE B: VOCABULARIO VCARD EXPRESADO EN XML Página 7 de 85

8 LISTA DE FIGURAS Y TABLAS Figura 1. Lecturas recomendadas en GEL-XML Figura 2. Estructura de directorios para el manejo de Esquemas Figura 3. Inclusión de elementos de área o módulos iguales Figura 4. Inclusión de elementos en bibliotecas Página 8 de 85

9 DERECHOS DE AUTOR Amenos que se indique de forma contraria, el copyright del texto incluido en este documento es del Gobierno de la República de Colombia. Se PUEDE reproducir gratuitamente en cualquier formato o medio sin requerir un permiso expreso para ello, bajo las siguientes condiciones: 1. El texto particular no se ha indicado como excluido y por lo tanto NO PUEDE ser copiado o distribuido. 2. La copia no se hace con el fin de distribuirla comercialmente. 3. Los materiales se DEBEN reproducir exactamente y no se deben utilizar en un contexto engañoso. 4. Las copias serán acompañadas por las palabras "copiado/distribuido con permiso del Gobierno de la República de Colombia. Todos los derechos reservados." 5. El título del documento DEBE ser incluido al ser reproducido como parte de otra publicación o servicio. Si se desea copiar o distribuir el documento con otros propósitos, DEBE solicitar el permiso entrando en contacto con el programa Agenda de Conectividad del Ministerio de Comunicaciones de la República de Colombia. Página 9 de 85

10 CRÉDITOS L a información y datos contenidos en la versión 1.0 del documento fueron elaborados inicialmente por la Unión Temporal Hewlett Packard-Microsoft y TELECOM dentro del marco del proyecto Plataforma de Interoperabilidad PDI, en julio de A partir de la versión 1.0a del documento, la información y datos incluidos en este documento, hacen parte de las observaciones, comentarios, aportes e investigaciones realizadas por el Grupo de Trabajo Interinstitucional establecido para tal fin y denominado Equipo GEL-XLM. Este equipo ha estado conformado las siguientes Entidades: DEPARTAMENTO ADMINISTRATIVO NACIONAL DE ESTADÍSTICA DANE. DEPARTAMENTO NACIONAL DE PLANEACIÓN DNP. MINISTERIO DE COMUNICACIONES: PROGRAMA AGENDA DE CONECTIVIDAD. MINISTERIO DE HACIENDA Y CRÉDITO PÚBLICO. MINISTERIO DE LA PROTECCIÓN SOCIAL MPS: PROGRAMA DE APOYO A LA REFORMA EN SALUD El equipo GEL-XML ha tomado como base, para la ejecución de las actividades, aspectos metodológicos y las experiencias que sobre el tema se han liderado por parte de otros gobiernos, como los de Alemania 1, Nueva Zelanda 2, Australia 3, Reino Unido 4 y Hong Kong 5, al igual que la Iniciativa de Metadatos Dublín Core DCMI 6, para efectos de estandarizar el manejo de metadatos para los elementos de dato que se han identificado y para la inclusión de dichos metadatos dentro de los esquemas creados. La empresa Informática Siglo 21, en el año 2008, propuso y aplicó recomendaciones sobre los documentos que definen y describen GEL-XML, sobre la estructura y funcionalidad respecto al organismo responsable de la administración y gestión del estándar, en el marco del proyecto de Consultoría para la Administración y Gestión de GEL-XML. 1 Tomado de el 22 de abril de Tomado de el 22 de abril de Tomado de el 22 de abril de Tomado de el 22 de abril de Tomado de el 22 de abril de Tomado de el 22 de abril de 2008 Página 10 de 85

11 1 INTRODUCCIÓN G EL-XML, Gobierno En Línea extensible Markup Language, está definido como el lenguaje común a utilizar en el ámbito de la iniciativa de Gobierno en Línea. El estándar GEL-XML consiste en un juego de guías o reglas para la creación de documentos electrónicos. Estos documentos serán utilizados por diferentes aplicaciones para comunicarse con el núcleo de Gobierno en Línea. El presente documento tiene como finalidad establecer las reglas básicas para la creación y mantenimiento de los esquemas dentro de la especificación del estándar GEL-XML. La recomendación base para la creación de esquemas XML la define el W3C (World Wide Web Consortium) y se encuentra en la página Web Se entiende por esquema en este documento un documento-xml que utiliza la definición XML-Schema 7 de la W3C. El documento está divido en cuatro secciones así: una sección de Guías para la Generación de esquemas, donde se encuentran los lineamientos básicos de la generación de esquemas, la metodología de versionamiento y otras recomendaciones; Una sección con guías para los componentes de esquemas, una sección con guías para el manejo de bibliotecas y una última sección con información de metadatos. 7 Tomado de el 4 de Junio de 2008 Página 11 de 85

12 2 AUDIENCIA Este documento está dirigido al personal que se encuentre a cargo de la administración del estándar GEL-XML. Este cuerpo regulador tiene la responsabilidad de asegurar que los diferentes entes que participan en Gobierno en Línea cumplan con todas las reglas establecidas en el estándar GEL-XML. Adicionalmente aquellas entidades u organizaciones interesadas en participar en la iniciativa de Gobierno en Línea, encontrarán en este documento información técnica normativa de la creación de esquemas XML que cumplan con el estándar GEL-XML, que les permitirá intercambiar información para integrarse a esta estrategia. Este documento no es un tutorial de los aspectos técnicos de XML o de esquemas. Para el entendimiento del contenido de este escrito se asume que el lector tiene conocimiento sobre XML, esquemas y la terminología relacionada. La figura 1 ilustra una guía para abordar el conocimiento y lectura de los documentos que sobre GEL-XML se han publicado a la fecha. Figura 1. Lecturas recomendadas en GEL-XML Página 12 de 85

13 3 REQUISITOS El lector DEBERÁ tener sólidos conocimientos en XML 8. Además, para contextualizar al lector, se recomienda la lectura previa de los siguientes documentos: Arquitectura de datos de GEL-XML Recomendación para la creación de esquemas de la W3C 9 Si el lector desea crear o utilizar adaptadores deberá tener profundos conocimientos en: Expresiones XPath 10 Programación en XSL Transformations 11 8 Tomado de el 23 de abril de Tomado de el 22 de abril de XPath es el acrónimo de XML Path Languaje, es un lenguaje para seleccionar nodos en un documento XML. Para mayor información visitar 11 XSL es el acrónimo de Extensible Stylesheet Language (Lenguaje Extensible para Hojas de Estilo), para mayor información visitar Página 13 de 85

14 4 CONCEPTOS BÁSICOS El estándar GEL-XML establece a XML como el lenguaje primario para la integración de datos en el marco de definiciones de la estrategia de Gobierno En Línea. XML permite codificar de manera sencilla y en formato texto la información del negocio requerida para las operaciones de Gobierno en Línea. Los esquemas GEL-XML se adhieren a los estándares recomendados por W3C 12. Dado que el W3C por medio de XML permite una gran flexibilidad para la creación de esquemas, el objetivo de este documento es proveer recomendaciones específicas y guías para el desarrollo de los esquemas dentro del marco GEL-XML. En particular, el estándar GEL-XML ofrece mecanismos para la reutilización de las definiciones; éstas DEBEN ser utilizadas selectivamente y manejadas cuidadosamente en el contexto de GEL-XML. Es importante que la reutilización de los esquemas sea de fácil compresión para los desarrolladores de las aplicaciones; razón por la cual, las definiciones enfatizan en la simplicidad y facilidad de uso antes que la elegancia técnica. Este documento integra muchos de los aspectos publicados en el documento e- Government Schema Guidelines for XML 13, Otros aspectos del documento se han adaptado conforme a la necesidades Colombianas y a la Arquitectura de datos GEL-XML. 12 Siglas de World Wide Web Consortium, abreviadamente W3C, es una organización que produce estándares para la World Wide Web. Está conformada por representantes de aquellas compañías que tienen intereses en la Internet ( 13 Tomado de el 15 de enero de 2009 (Crown Copyright 2002) Página 14 de 85

15 5 ESTRUCTURA Y TERMINOLOGÍA 5.1 ESTRUCTURA Este documento está dividido en varias secciones relacionadas con diferentes aspectos del diseño de esquemas: o o o o Guías para la generación de esquemas GEL-XML Guías de componentes de esquemas GEL-XML Bibliotecas comunes Metadatos y Esquemas Para facilitar el aprendizaje y la comprensión de las reglas, cada sección incluye una introducción al tema y especifica un conjunto de guías que manejan la siguiente estructura: Guía : Provee el resumen del requerimiento o recomendación a utilizar. : Provee información más detallada sobre la razón para la adopción de la guía. Ejemplo : Opcionalmente provee algunos ejemplos del uso de la guía en particular. 5.2 TERMINOLOGÍA Los términos Schema XML, Esquema XML, Documento de Schema XML y Esquema con frecuencia son utilizados indiferentemente para hacer referencia a los documentos XML que contienen elementos de esquemas expresados en XML como lo describe la recomendación del W3C. En este documento el término Esquema se acoge a la definición del W3C, como la estructura abstracta requerida para validar un documento XML. El término esquema- XML tiene el mismo significado. Durante el desarrollo del presente documento se hará mención al término esquema. Un Documento XML es una pieza completa de XML bien formado como lo define la recomendación de XML. Dado que la mayoría de los documentos XML en GEL-XML son utilizados para intercambiar información entre diferentes sistemas de información, ocasionalmente también es denominado Mensaje XML. Página 15 de 85

16 El término Bibliotecas Comunes son el conjunto de componentes del esquema que son usados en dos o más instancias. El término Instancia se refiere a un documento XML bien formado, que es válido según algún esquema de GEL-XML. La forma de referirse a los elementos Documento será como Instancia del Documento. Nótese que no existen instancias de documento válidas a partir de un esquema basado en bibliotecas comunes. Las bibliotecas comunes son exclusivamente para reutilización. En este documento, el término Elemento se refiere a un segmento bien formado de XML en una instancia. Ejemplo <Ciudadano> (Otras definiciones) </Ciudadano> En este caso <Ciudadano> es un elemento. El término componente se refiere a la definición de un elemento en un esquema. Ejemplo <xsd:complextype name= tipociudadano > (Otras definiciones) </xsd:complextype> En este caso tipociudadano es un componente. Las palabras claves como "DEBE", "NO DEBE", "REQUERIDO,"OBLIGATORIO", "DEBERÁ", "NO DEBERÁ", "DEBERÍA", "NO DEBERÍA", "RECOMENDADO", "PUEDE" y "OPCIONAL" en este documento serán interpretadas como se describe en RFC Ver apéndice A. Página 16 de 85

17 6 GUÍAS PARA LA GENERACIÓN DE ESQUEMAS GEL-XML Este capítulo provee directrices sobre el diseño de datos, los requerimientos y convenciones relacionados con los esquemas que se van a utilizar en GEL-XML. La generación de los esquemas basados en XML asegura la portabilidad y la disponibilidad de la información. 6.1 LINEAMIENTOS INÍCIALES Lenguaje para la especificación de los esquemas Los esquemas XML del W3C DEBEN ser utilizados como el lenguaje para la definición de documentos en el estándar GEL-XML. Es importante para la interoperabilidad de todos los sistemas de gobierno, el uso de un mecanismo único para la descripción de los documentos. En la actualidad solo dos mecanismos cubren los requerimientos de GEL-XML, éstos son los DTD s y los esquemas. De éstos los esquemas son preferibles por su soporte de espacios de nombre 14, tipos de datos y diseño modular. b) Guía Los esquemas GEL-XML DEBEN usar la cadena de texto xsd como prefijo para el espacio de nombres del lenguaje XML esquema 15. Esta es una convención aceptada internacionalmente para el manejo de XML. 14 Un espacio de nombres (namespace) es un prefijo que se utiliza para cualificar (dar características) a nombres de elementos XML o atributos XML. El espacio de nombres permite que los atributos y elementos tengan nombres únicos dentro de un documento XML, evitando ambigüedades con otros elementos o atributos con nombres iguales. Por ejemplo, en la cadena xsd:string el prefijo del espacio de nombres es xsd y el nombre es string. 15 Tomado de el 1 de mayo de 2008 Página 17 de 85

18 Ejemplo <xsd:schema xmlns:xsd=" xmlns:secadq = XML/1.0/schemas/Proyectos/SECOP/Adquisicion/Adquisicion targetnamespace= " XML/1.0/schemas/Proyectos/SECOP/Adquisicion" version="1.0" id="cabeceraadquisicion"> Detalles del diseño en XML Todas las reglas de diseño de los esquemas GEL-XML DEBEN estar basadas en las recomendaciones del W3C Uno de los objetivos de diseñar las bibliotecas para los esquemas de GEL-XML, es permitir la máxima reutilización de los componentes con el fin generar al proceso bastante flexibilidad y granularidad Patrones del diseño de esquemas XML Se DEBERÁ utilizar patrones de diseño para la creación de esquemas. Se recomienda el uso del patrón de diseño Venetian Blind 16 por sus características de reutilización elementos. El Patrón de diseño Venetian Blind recomienda la creación de declaración de tipos de datos para luego definir elementos con dichos tipos de datos Los elementos- XML DEBEN estar en esquemas independientes. Ejemplo A continuación se presenta un ejemplo del patrón Venetian Blind; el ejemplo define cinco elementos. Cada uno de los elementos-xml (que definen un elemento-xml) del 1 al 4 PUEDE estar en esquemas independientes. El elemento-xml 4 es el 16 Tomado de el 22 de abril de Página 18 de 85

19 que agrupa los demás elementos-xml completando así el patrón Venetian Blind. El elemento-xml 5 es la utilización del elemento-xml 4. Definición del elemento-xml 1: <xsd:simpletype name= enumtitulo > <xsd:restriction base= xsd:string > <xsd:enumeration value= Sr. /> <xsd:enumeration value= Sra. /> <xsd:enumeration value= Ing. /> </xsd:restriction> </xsd:simpletype> Definición del elemento-xml 2: <xsd:simpletype name= tipoprimernombre > <xsd:restriction base= xsd:string > <xsd:minlength value= 1 /> </xsd:restriction> </xsd:simpletype> Definición del elemento-xml 3: <xsd:simpletype name= tipoprimerapellido > <xsd:restriction base= xsd:string > <xsd:minlength value= 1 /> </xsd:restriction> </xsd:simpletype> Definición del elemento-xml 4: <xsd:complextype name="tiponombre"> <xsd:sequence> <xsd:element name= Titulo type= enumtitulo /> <xsd:element name= Nombre type= tipoprimernombre /> <xsd:element name= Apellido type= tipoprimerapellido /> </xsd:sequence> </xsd:complextype> Definición del elemento-xml 5: <xsd:element name= NombrePersona type= tiponombre /> Página 19 de 85

20 6.1.4 Complejidad de los esquemas Es importante tener siempre en cuenta a la audiencia. Las características menos comunes de los esquemas NO DEBERÁN ser utilizadas cuando existan opciones más simples. Los desarrolladores DEBERÁN tener en cuenta la complejidad de las pruebas sobre los esquemas. Esta es una de las reglas más importantes. El lenguaje XML es enormemente poderoso y flexible en cuanto a la definición de esquemas se refiere. En muchos casos los esquemas pueden simplificarse y aún alcanzar el mismo fin. Siendo esta tecnología novedosa, son muchas las personas que necesitarán hacer uso de los esquemas, y algunas tendrán poca experiencia con los mismos, por lo que en estas circunstancias, la mejor estrategia es mantener la simplicidad. Adicionalmente, muchas herramientas para el desarrollo de esquemas, tienden a contener errores (bugs) en las opciones menos populares. Los esquemas simples no solo son más fáciles de probar, sino que también causarán menos confusión al no exponer debilidades en las herramientas de desarrollo Modelar datos, no formularios Los esquemas XML DEBERÁN modelar los datos requeridos por las aplicaciones, en lugar de formularios o formatos de mensaje predefinidos. Si bien es cierto que los formularios constituyen un buen punto de referencia, NO DEBERÁN dominar el diseño final. Hay dos razones para esto. La primera es que los formularios son diseñados para ser utilizados en papel, no en la pantalla de un computador, adicionalmente los formatos preexistentes pueden no representar en forma estructurada y lógica las necesidades reales de los datos en el sistema. En segundo lugar, todos los esquemas del estándar GEL-XML DEBERÁN derivarse de las necesidades de datos directamente, en lugar de seguir ciegamente formatos preestablecidos Nombre de los archivos que contienen los esquemas Los archivos en producción DEBEN utilizar el nombre de los elementos que contienen. En caso que el esquema sea una biblioteca se DEBERÁ utilizar el Página 20 de 85

21 formato UCC 17, y en caso que sea un elemento de dato se utilizará el formato LCC 18. Esta regla permite identificar fácilmente cada palabra utilizada en el nombramiento y además relacionar los elementos con el archivo que los contiene. Ejemplo PresentacionProyectos.xsd ó tipociudadano.xsd b) Guía Los nombres de los esquemas DEBEN reflejar aspectos funcionales del mensaje que representan. Se DEBERÍA utilizar el mismo nombre del elemento de dato que representan y en consecuencia, seguir las reglas de nombramiento para elementos de datos del documento de Arquitectura de Datos. Esta regla busca facilitar la comprensión de los esquemas. En la mayoría de los casos, si el mensaje representa un proceso, el nombre del esquema podrá ser igual al nombre del proceso. Ejemplo tipocertificadojudicialconsularent.xsd es el elemento de dato que contiene la información de entrada del certificado judicial consular. Éste es expedido por el funcionario consular, de acuerdo con la información suministrada por el departamento administrativo de seguridad DAS, en el cual se certifica que el titular no tiene asuntos pendientes con las autoridades judiciales y de policía Reutilización de elementos b) Guía Se DEBERÁN reutilizar los elementos que tengan la misma semántica. La reutilización se DEBERÁ realizar por medio de la inclusión o importación del 17 UCC Acrónimo de la lengua inglesa para representar Upper Camel Case, que significa que todos los inicios de palabras comienzan con mayúsculas. Ejemplo: TodasEnMayusculas. 18 LCC Acrónimo de la lengua inglesa para representar Lower Camel Case, que significa que todos los inicios de palabras comienzan con mayúsculas, excepto la primera palabra. Ejemplo: primeraenminuscula. Página 21 de 85

22 esquema que contiene elemento de dato junto con el uso del los atributos name y type dentro de la etiqueta element. La reutilización de elementos facilita el intercambio entre entidades. Ejemplo En el esquema de la fecha (apenas un extracto para ilustrar la reutilización, nótese la creación del elemento fechaexpedicion): xmlns:comtem=" XML/1.0/schemas/Comun/Temporal" <xsd:simpletype name="tipofecha"> <xsd:restriction base="xsd:date"> <xsd:mininclusive value=" "/> </xsd:restriction> </xsd:simpletype> En el esquema que usa la fecha (note la referencia al elemento de dato tipofecha creado en el esquema de arriba) xmlns:comtem= XML/1.0/schemas/Comun/Temporal <xsd:import namespace=" XML/1.0/schemas/Comun/Temporal" schemalocation="../../../comun/temporal/ Temporal.xsd"/> <xsd:complextype name="tipodatopersonal"> <xsd:sequence> <xsd:element name="fechaexpedicion" type="comtem:tipofecha"/> </xsd:sequence> </xsd:complextype> Página 22 de 85

23 6.2 VERSIONAMIENTO Políticas de versionamiento El ciclo de versionamiento de los esquemas de Gobierno en Línea será independiente del ciclo de versionamiento del estándar GEL-XML y también será independiente de la versión de la definición del elemento de dato (arquitectura y plantilla de metadatos). Sin embargo, los esquemas DEBERÁN cumplir con la versión más reciente de la arquitectura al momento de su creación. El objetivo de utilizar la política de versiones es solucionar inconvenientes de incompatibilidad entre dos liberaciones sucesivas de esquemas de Gobierno en Línea. Así mismo solucionar los problemas presentados al realizar cualquier tipo de cambio en las bibliotecas comunes. El ciclo de versionamiento del estándar GEL-XML PUEDE ser largo, dado que un cambio en la especificación DEBE ser estudiado cuidadosamente. Los esquemas generados bajo una versión dada de GEL-XML no serán forzados a cambiar cuando cambie la versión de GEL-XML. De la misma manera, los esquemas generados bajo una versión de GEL-XML no tienen que esperar un cambio en la versión de GEL-XML para ser publicados bajo una nueva versión Mecanismo propuesto para el manejo de versiones Los esquemas GEL-XML no soportarán la compatibilidad hacia adelante. Ejemplificando el concepto podemos decir que la compatibilidad hacia adelante se define como la situación en que una persona llamada Remitente o Emisor crea y envía una Instancia basada en un nuevo esquema a otra persona llamada Recipiente o Receptor, el cual al hacer la recepción de la instancia, la valida contra un esquema viejo y éste DEBE validarse sin que se generen fallas por tratarse de una instancia de esquema posterior. La compatibilidad hacia adelante se define como la capacidad de diseñar esquemas tales que hasta el esquema más viejo PUEDE validar los documentos de caso creados siguiendo la versión más reciente definida. Página 23 de 85

24 6.2.3 Reflejar los números de la versión en el esquema Tanto las versiones mayores como las versiones menores serán representadas usando solo caracteres numéricos. La representación completa de la versión será del formato mm.nn o Mayorversion. Menorversion, donde mm es un número que representa la versión mayor y nn es un número que representa la versión menor. Todo los esquemas DEBEN tener la versión en el atributo version del elemento xsd:schema Esta es una guía que provee consistencia al estándar GEL-XML Cambios que pueden ser incorporados a una versión menor Los siguientes cambios implican un cambio de versión menor: Adición de nuevos elementos opcionales o atributos opcionales. Cambio en los atributos, de obligatorio a opcional. Cambio de elementos cardinales de un viejo esquema [0..1] a nuevo esquema [0..*]. Cambio de elementos cardinales de un viejo esquema [1..1] a nuevo esquema [1..*]. Cambios compatibles hacia atrás en los patrones de validación de componentes. Adición de un término a una lista enumerada. Estas reglas son consistentes con la intención de ser compatibles hacia atrás, pero no hacia delante Cambios que implican un cambio de versión mayor Los siguientes cambios implican un cambio de versión mayor: Cambio en los atributos de opcional a obligatorio. Página 24 de 85

25 Adición de un elemento obligatorio. Adición de un atributo obligatorio. Eliminación de un elemento opcional. Eliminación de un elemento obligatorio. Eliminación de un atributo XML opcional. Eliminación de un atributo obligatorio. Cambio de un atributo o nombre de una etiqueta de un elemento. Cambio de elementos cardinales de un viejo esquema [0..*] a nuevo esquema [0..1]. Cambio de elementos cardinales de un viejo esquema [1..*] a nuevo esquema [1]. Cambio en la secuencia de los elementos en una etiqueta <xsd:sequence>. Cambios NO compatibles hacia atrás en los patrones de validación de componentes. Quitar un término de una lista enumerada. Los cambios mayores de versión no son necesariamente compatibles hacia atrás Reflejar los números de las versiones menores Para reflejar el cambio de una versión menor simplemente se DEBE cambiar el número de la versión en el atributo al comienzo del esquema XML. Es fácil de usar teniendo en cuenta que esto es una parte de la especificación del esquema. Las instancias no se tendrían que cambiar si permanecen válidas con la nueva versión del esquema, que es nuestra exigencia de compatibilidad hacia atrás. La única desventaja es que cuando el esquema pase por un validador, no tendrá en cuenta el atributo de la versión. En parte, esto es mitigado reflejando en el espacio de nombres la versión mayor del esquema. Ejemplo <xsd:schema targetnamespace=" XML/1.0/schemas/proyectos/artesanias/presentacionproyectos/PresentacionProye ctos" xmlns:xsd=" xmlns:arte=" XML/1.0/schemas/proyectos/artesanias/presentacionproyectos/PresentacionProye ctos" version="1.2"> Página 25 de 85

26 Pasa a: <xsd:schema targetnamespace=" XML/1.0/schemas/proyectos/artesanias/presentacionproyectos/PresentacionProye ctos" xmlns:xsd=" xmlns:arte=" XML/1.0/schemas/proyectos/artesanias/presentacionproyectos/PresentacionProye ctos" version="1.3"> Reflejar los números de la versión en las instancias Las instancias GEL-XML PODRÁN usar el atributo de "versiondocumento" definido en el elemento tipodocumento para reflejar la versión completa. El documento del esquema usa el atributo interno de versión para reflejar la versión completa del esquema (tanto la versión mayor como la menor). Dado que la versión mayor es reflejada en el targetnamespace, la instancia ya contiene dicha versión. Sin embargo, también se tiene que asegurar que la versión completa sea especificada en la instancia. Esto es esencial porque si la instancia no contiene la información de la versión menor y la compatibilidad hacia adelante no es soportada entre las dos versiones mayores, los sistemas de aplicación tendrían que rechazar las instancias hasta conocer que versión tienen todos los entes conectados. Ejemplo Esta clase es definida como: <xsd:complextype name="tipodocumento" abstract="true"> <xsd:attribute name="versiondocumento" type="string" fixed="1.3"/> </xsd:complextype> Sin embargo, después de realizar la liberación, el atributo "versiondocumento" tendrá un valor fijo. En cambio los entes gubernamentales conectados especificarán el valor de este atributo para reflejar la versión mayor y menor que utilizan. Página 26 de 85

27 6.2.8 Las reglas sobre la versión mayor y menor que aplican a esquemas de listas de valores conocidos Para aquellas listas de valores 19 conocidos para las cuales GEL-XML tiene definido su propio esquema, se DEBEN seguir las siguientes reglas de versionamiento: La adición de valores en los códigos constituye un cambio de versión menor. Cualquier cambio o eliminación de los códigos de valores existentes constituyen un cambio de versión Mayor. Esta guía es consistente con las reglas de manejo de versiones de los esquemas Las reglas de compatibilidad de versiones Todas las versiones menores de un esquema dentro de una versión mayor serán compatibles hacia atrás. Las versiones menores son las liberaciones intermedias de un esquema XML que contiene sólo los cambios que son considerados compatibles hacia atrás con la versión existente de este esquema. Las versiones mayores son las liberaciones de una suite de los esquemas XML que contiene los cambios que no son compatibles hacia adelante con la suite existente de los mismos esquemas. 6.3 RELATIVAS A LOS ELEMENTOS Modelado de los elementos Los tipos de datos básicos definidos por WC3 DEBEN ser usados siempre que se pueda, en lugar de crear tipos equivalentes con otros nombres. 19 Una lista de valores, como su nombre lo dice, es un conjunto ordenado de valores que puede tomar un elemento. Por ejemplo, el factor sanguíneo de Rhesus (factor Rh) se puede representar como una lista de valores, así: Positivo, Negativo. Página 27 de 85

28 Los tipos básicos están bien definidos por el WC3 y por tanto son de amplia comprensión por parte de los desarrolladores. Usar otros nombres para los mismos tipos puede causar confusión y posiblemente problemas durante la validación. b) Guía Tipos complejos (ComplexTypes) con contenido simple DEBERÁN ser utilizados siempre que sea posible. El contenido simple permite almacenar datos sencillos, sin hijos. En general, lo que diferencia a un tipo simple (SimpleType) de uno complejo con contenido simple es que el segundo, más tarde puede soportar atributos. Ejemplo <xsd:simpletype name="tipoelemento"> </xsd:simpletype> <xsd:complextype name="tipoelmismoelemento"> <xsd:complexcontent> <xsd:attribute name="version" fixed="1.2"/> </xsd:complexcontent> </xsd:complextype> c) Guía Los tipos complejos con hijos DEBERÁN utilizarse siempre que sea posible. Los tipos complejos con hijos permiten expresar relaciones de contenedorcontenido. Ejemplo <xsd:complextype name="tipodireccion"> <xsd:sequence> <xsd:element name=" codpais" type="comubi:tipocodpais" /> <xsd:element name="coddivisionterritorial" type=" comubi:tipocoddivisionterritorial" minoccurs="0"/> <xsd:element name="nomciudad" type="comubi:tiponomciudad" /> <xsd:element name="nombredireccion" Página 28 de 85

29 type="geltd:tipocadena256 /> <xsd:element name="zonapostal" type="comubi:tipozonapostal" minoccurs="0"/> </xsd:sequence> </xsd:complextype> d) Guía Cuando se modelen grupos de elementos, la instrucción <xsd:sequence> es la manera preferida de representarlos. El uso de <xsd:all> no es RECOMENDADO. <xsd:all> está limitado por el hecho de que la estructura no puede repetirse. Esto limita el uso de <xsd:all> a la primera ocurrencia de su juego de elementos. Si el modelo requiere elementos que se repiten más de una vez, <xsd:all> no puede usarse. Ejemplo <xsd:complextype name="tiponompersona"> <xsd:sequence> <xsd:element name="primerapellido" type="comper:tipoprimerapellido"/> <xsd:element name="tiposegundoapellido" type="comper:tiposegundoapellido"/> <xsd:element name="primernombre" type="comper:tipoprimernombre"/> <xsd:element name="segundonombre" type="comper:tiposegundonombre" /> </xsd:sequence> </xsd:complextype> e) Guía El uso de la funcionalidad de nillability no es RECOMENDADO. El atributo nillability se utiliza para especificar que un elemento no va en un documento XML. El soporte de esta funcionalidad, en los analizadores de XML, en general es pobre. Normalmente será posible conseguir una estructura equivalente utilizando elementos opcionales. Página 29 de 85

30 6.3.2 Data Types vs. Declaración de Elementos En muchos casos se presentará la disyuntiva sobre si un componente reutilizable DEBE ser definido como un tipo de dato (simple o compuesto) o como una declaración de elemento. Un componente PODRÍA ser definido como tipo de dato sí: Va a ser utilizado con diferentes nombres en diferentes contextos. Se espera que otros tipos sean derivados de él. Un componente PODRÍA ser definido como una declaración de un elemento sí: No existe la intención de derivar otros elementos de él. El elemento será utilizado siempre con el mismo nombre. Todos los elementos de la capa Tipos de datos GEL-XML DEBERÁN ser definidos como tipos de datos. Se presentarán múltiples situaciones en las que un elemento DEBE utilizarse sin cambiar su nombre. Por ejemplo el Número de Cédula de un ciudadano siempre DEBE aparecer como NumeroCedula, de manera que su semántica sea siempre clara y cuando dos sistemas independientes lo utilicen, será claro que se refieren al mismo elemento de dato. Sin embargo, en otras circunstancias no es apropiado fijar el nombre de un elemento de dato. Por ejemplo, una dirección tiene siempre la misma estructura, pero PUEDE aparecer como elementos diferentes con los nombres DireccionCasa, DireccionTrabajo o DireccionCorrespondencia. En este caso, el elemento Dirección DEBE ser definido como un tipo de dato. En este caso se dice que DireccionCasa o DireccionTrabajo son usos de Direccion, de acuerdo con la arquitectura definida. El otro criterio para decidir entre una declaración o un tipo, es la necesidad de derivar otros elementos de él. En este caso el uso de tipos de datos permite una semántica más clara, evitando el uso de la directiva xsd:redefine. Ejemplos En el ejemplo se muestra la reutilización del elemento lugar y de elementos de la capa Tipos de Dato GEL-XML que son definidos como tipos de dato. Ejemplo de utilización del tipo de dato cadena256, de la capa Tipos de Dato GEL- XML (ver elemento nombredireccion). Página 30 de 85

31 <xsd:complextype name="tipodireccion"> <xsd:sequence> <xsd:element name=" codpais" type="comubi:tipocodpais" /> <xsd:element name="coddivisionterritorial" type=" comubi:coddivisionterritorial" minoccurs="0"/> <xsd:element name="nomciudad" type="comubi:nomciudad" /> <xsd:element name="nombredireccion" type="geltd:tipocadena256 /> <xsd:element name="zonapostal" type="comubi:tipozonapostal" minoccurs="0"/> </xsd:sequence> </xsd:complextype> Ejemplo de la reutilización del elemento de dato lugar: Esquema del Elemento de dato lugar, incluyendo sus usos. <xsd:complextype name="tipotipolugar"> <xsd:sequence> <xsd:element name=" codpais" type="comubi:tipocodpais" /> <xsd:element name="coddivisionterritorial" type=" comubi:coddivisionterritorial" minoccurs="0"/> <xsd:element name="pais type="comubi:tipopais"/> <xsd:element name="divisionterritorial name="comubi:tipodivisionterritorial "/> <xsd:element name="subdivisionterritorial" name="comubi:tiposubdivisionterritorial"/> </xsd:sequence> </xsd:complextype> Utilización de los usos lugarexpedición y lugarnacimiento, del elemento de dato Lugar, dentro del elemento de dato tipodatopersonal <xsd:complextype name="tipodatopersonal"> <xsd:sequence> <xsd:element name="nompersona" type="comper:tiponompersona"/> <xsd:element name="codtipoididpersona" type="locide:tipocodtipoididpersona"/> <xsd:element name="lugarnacimiento" type="comubi:tipotipolugar"/> <xsd:element name="lugarexpedicion" type="comubi:tipotipolugar"/> Página 31 de 85

32 </xsd:sequence> </xsd:complextype> b) Guía Los esquemas GEL-XML NO DEBEN tener un espacio de nombres por defecto. Esta técnica es la que mejor funciona cuando se utilizan múltiples espacio de nombres. Dado que GEL-XML utiliza múltiples espacio de nombres, es imperativo que los diferentes componentes mantengan el espacio de nombres donde se definan Atributos vs. Elementos Los esquemas de GEL-XML DEBEN estar definidos de manera que los elementos sean los principales contenedores de información. Los atributos son más apropiados para almacenar datos adicionales y elementos simples que proveen más información sobre el contenido. Los atributos NO DEBEN ser utilizados para calificar a otros atributos, ya que esto causa confusión. A diferencia de los elementos, los atributos no pueden almacenar datos estructurados. Por esta razón, los elementos son el mecanismo preferido para almacenar datos. Los atributos son más apropiados para almacenar metadatos acerca de los elementos. Ejemplo Una fecha PUEDE ser representada en un mensaje como: <FechaNacimiento> </FechaNacimiento> Si se requiere información adicional, como por ejemplo, el método de verificación, PUEDE usarse un atributo como el siguiente: <fechanacimiento verificadamediante= Visualización de cedula > </fechanacimiento> Página 32 de 85

33 La siguiente estructura sería inapropiada: <fechanacimiento codigo= 2 verificadamediante= Visualización de cedula > </fechanacimiento> En este caso, no es claro si el atributo código aplica a verificadamediante o al elemento en sí. La estructura correcta en este caso sería: <fechanacimientoverificada > <VerificadaMediante > Visualización de cedula </VerificadaMediante> <codigoverificacion> 2 </codigoverificacion> < fechanacimiento> </fechanacimiento > </fechanacimientoverificada> 6.4 OTRAS RECOMENDACIONES Referencias absolutas y relativas Cuando los esquemas estén estrechamente relacionados de tal forma que se espere que siempre sean almacenados juntos en una estructura de directorios consistente, las sentencias import y export DEBERÁN usar referencias relativas. Es posible que los esquemas sean movidos de un lugar a otro. En estos casos, es importante que las referencias a otros esquemas se mantengan. Los grupos de esquemas que probablemente sean movidos juntos pueden preservar las relaciones usando referencias relativas. Si este no es el caso, se necesitan referencias absolutas. b) Guía Los esquemas de GEL-XML estarán almacenados organizadamente en una estructura de directorios que represente la taxonomía de todo el sistema. Página 33 de 85

34 Almacenar los esquemas de manera organizada facilita el uso y mantenimiento de los mismos. Ejemplo Esquema propuesto: Figura 2. Estructura de directorios para el manejo de Esquemas Uso de instancias de ejemplo Cuando se publican esquemas, DEBERÍA incluirse al menos una instancia válida del documento XML. Las instancias de los documentos ejemplo tienen varios usos. En primer lugar, los ejemplos contribuyen a la comprensión del esquema. Segundo, al generar una instancia válida se pueden poner en evidencia malas prácticas que hagan a la instancia difícil de generar o leer. Y finalmente, muchas herramientas de desarrollo Página 34 de 85

35 hacen un mejor trabajo probando el esquema cuando se utilizan para validar una instancia Esquemas de mensajes Un esquema de mensaje DEBERÍA representar un solo tipo de mensaje XML. La meta aquí es permitir el reutilización de mensajes sin tener esquemas de mensajes excesivamente complejos. Aunque es tentador utilizar la flexibilidad de XML para definir esquemas sofisticados que representen grupos de mensajes relacionados, esto no es conveniente. En particular DEBE evitarse tener un esquema tal que al cambiar un elemento en un mensaje, otros mensajes resulten afectados. Cuando un grupo de mensajes use un contenido muy similar, DEBE decidirse entre crear un esquema de mensaje para cada mensaje del grupo, o crear una biblioteca común que contenga los elementos compartidos Definición de conjuntos de valores conocidos La representación de conjuntos de valores conocidos DEBEN codificarse utilizando la recomendación descrita en el Code List Task Group Final Report" 20. Si dentro de estas recomendaciones no existe un esquema que satisfaga los requerimientos, PUEDE entrar a evaluar la creación de una biblioteca común. Estos conjuntos de valores encontrados en la recomendación son internacionalmente aceptados para representar elementos como países, monedas, unidades de medida, etc. inclusive provee los esquemas con las enumeraciones definidas. 20 Los valores pueden consultarse en: Página 35 de 85

36 Ejemplo Cuando se desea designar la unidad de medida de un valor, por medio de un código, en el caso de ser kilogramos por litro se utilizara el código B35. El código para denominar pesos colombianos es COP. 6.5 REPRESENTANDO CONDICIONES ALTERNAS Las condiciones alternas (una condición alterna denota un estado que puede tener un componente) DEBEN ser representadas utilizando elementos o atributos en lugar de codificarlas mediante la presencia o ausencia. En XML es posible tener un elemento opcional, lo cual permite codificar la presencia de un elemento como un SI y la ausencia como un NO. En GEL-XML para aumentar la claridad de los esquemas, los elementos siempre DEBEN estar presentes y se incluye un elemento o atributo cuyos valores serán los literales SI o NO. Ejemplo Supongamos que tenemos un elemento que representa a un ciudadano y que a su vez ésta tiene un atributo para indicar si es un contribuyente especial: <Ciudadano> (otros datos) <ContribuyenteEspecial/> </Ciudadano> Un estilo para representar el hecho de que el ciudadano NO es un contribuyente especial, es omitir el atributo, esta manera de representación es valida para XML pero no para GEL-XML. La falta del elemento <ContribuyenteEspecial/> PUEDE interpretarse como que el ciudadano NO es un contribuyente especial: <Ciudadano> (otros datos) </Ciudadano> Para evitar este tipo de dualidades, en las interpretaciones, en los esquemas de GEL-XML se DEBEN representar de la siguiente manera: Página 36 de 85

37 <Ciudadano> (otros datos) <ContribuyenteEspecial>NO </ContribuyenteEspecial/> </Ciudadano> 6.6 COMENTARIOS EN LOS ESQUEMAS En el estándar GEL-XML, los comentarios se expresan mediante el elemento documentation y no mediante comentarios XML. El elemento xsd:documentation existe con el propósito de ayudar a documentar los esquemas. La ventaja principal de usar esta estructura, en contraposición a utilizar comentarios XML es que pueden ser procesados con hojas de estilos para producir documentación de usuario. Además, se DEBERÁN utilizar elementos Dublin Core para incluir los comentarios y especificar el lenguaje de los comentarios con la marca xml:lang. El elemento xsd:annotation describe el elemento padre. El elemento xsd:documentation hijo de un elemento describe el esquema para lectores humanos. El elemento hijo xsd:appinfo describe el esquema para programas de computador. Ejemplo <xsd:annotation> <xsd:appinfo> <dc:identifier> XML/1.0/schemas/Proyectos/SECOP/Adquisicion/tipoLineaIt emadj</dc:identifier> <dc:creator xml:lang="es">ministerio de Comunicaciones: Programa Agenda de Conectividad</dc:creator> <dc:issued> </dc:issued> <dc:description xml:lang="es">elementos de identificación y descriptivos básicos de bienes, servicios u obras para los distintos elementos involucrados en el proceso de contratación con información especifica de la adjudicación.</dc:description> <dc:hasversion>1.0</dc:hasversion> </xsd:appinfo> </xsd:annotation> Página 37 de 85

38 6.7 MECANISMOS DE REUTILIZACIÓN El uso de xsd:redefine en lo posible DEBE evitarse. Esta regla evita efectos secundarios en componentes reutilizados, al tiempo que aumenta la claridad y legibilidad. Ejemplo Esquema principal: <xsd:complextype name="tipodatopersonal"> <xsd:sequence> <xsd:element name="nompersona" type="comper:tiponompersona"/> <xsd:element name=" lugarexpedicion" type="comubi:tipolugar"/> <xsd:element name="fechaexpedicion" type="comtem:tipofecha"/> <xsd:element name="comubi:lugarnacimiento" type="comubi:tipolugar"/> </xsd:sequence> </xsd:complextype> Esquema redefinido (la lectura es compleja): <xs:redefine schemalocation="[ ]../esquemaprincipal.xsd"> <xs:complextype name="tipodatopersonal"> <xs:complexcontent> <xs:extension base="tipodatopersonal"> <xs:sequence> <xs:element name="paisresidencia" type="comubi:tipopais"/> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> </xs:redefine> b) Guía El elemento xsd:import NO DEBE usarse sin espacio de nombres. Página 38 de 85

39 Si es usado sin espacio de nombres, xsd:import permite referenciar elementos externos sin targetnamespace. Esto causa que los esquemas sean difíciles de depurar y actualizar. c) Guía La instrucción <xsd:include> PUEDE ser utilizada, siempre y cuando el esquema incluido tenga el mismo espacio de nombres que el que lo incluye. Esta instrucción permite la reutilización de los esquemas. Sin embargo, se pueden presentar problemas si se utiliza para incluir esquemas que tengan un espacio de nombres diferente al contexto donde se utiliza. En estos casos DEBE usarse la instrucción <xsd:import>. d) Guía La sentencia <xsd:import> siempre DEBE incluir el atributo schemalocation. Mediante este atributo puede localizarse el esquema que está siendo importado. e) Guía Cuando se utilice la sentencia <xsd:import> DEBEN evitarse referencias circulares. Una referencia circular puede causar problemas a los sistemas de validación. f) Guía Cuando se utilice la sentencia <xsd:import> DEBEN evitarse las declaraciones repetidas. Las declaraciones repetidas aumentan la complejidad del esquema innecesariamente. Ejemplo <xsd:import targetnamespace=" XML/1.0/schemas/Comun/General" schemalocation="../../../comun/general/tipocantidad.xsd" /> Página 39 de 85