GEL-XML, LENGUAJE ESTÁNDAR DE INTERCAMBIO...

GGEELL--XXMMLL,, LLEENNGGUUAAJJEE EESSTTÁÁNNDDAARR DDEE IINNTTEERRCCAAMMBBIIOO DDEE IINNFFOORRMMAACCIIÓÓNN:: VVEERRSSIIOONNAAMMIIEENNTTOO

© República de Colombia - Derechos Reservados

Bogotá, D.C., Abril de 2009

GEL-XML LENGUAJE DE INTERCAMBIO DE

INFORMACIÓN VERSIONAMIENTO

Página 2 de 32

FFOORRMMAATTOO PPRREELLIIMMIINNAARR AALL DDOOCCUUMMEENNTTOO

Título: LENGUAJE DE INTERCAMBIO DE INFORMACIÓN: VERSIONAMIENTO.

Fecha elaboración aaaa-mm-dd: 2009-02-25

Sumario: – Consignar las prácticas de cambio de versión de cada uno de los componentes del Estándar GEL-XML. Se consideran componentes del Estándar GEL-XML a los elementos de dato (incluidas las definiciones de elementos de datos y esquemas), los documentos, y el Estándar GEL-XML.

Palabras Claves: Versionamiento, GEL-XML Formato: DOC Lenguaje: Español Fecha de publicación aaaa-mm-dd:

2009-02-25 Fecha de modificación aaaa-mm-dd: 2009-09-187

Dependencia: Ministerio de comunicaciones: Programa “Gobierno en Línea” – Proyecto Intranet Gubernamental.

Código: Versión: 6.0 Estado: Publicado Categoría: Estándares Autor (es): César Ariza

Líder Técnico - Informática Siglo 21

Firmas

Revisó: Luz Valderrama Consultor Técnico – Informática Siglo 21 Saulo Daza Consultor Técnico – Programa Agenda de Conectividad Nelson Rojas Casa Consultor Técnico – ISLSA

Aprobó: Mónica A. Monroy G. Gerente de Proyecto Informática Siglo 21 Johanna Pimiento Supervisor Contrato - Programa Agenda de Conectividad Carlos Ochoa Gerente de Interventoría ISL SA

Información Adicional:

Ubicación: El archivo magnético asociado al documento está localizado en http://gelxml.igob.gov.co.



Página 3 de 32

CONTROL DE CAMBIOS

VERSIÓN FECHA RESPONSABLE NATURALEZA 1.0 2008-10-10 Informática Siglo 21 Publicación versión inicial del documento.

1.1 2008-10-27 Informática Siglo 21 Inclusión de componentes versionables e identificación de

componentes.

2.1 2009-01-05 Informática Siglo 21 Ajustes al Documento según observaciones recibidas.

3.1 2009-02-25 Informática Siglo 21 Ajustes la documento según las observaciones recibidas

4.0 2009-04-02 Informática Siglo 21 Unión de los dos documentos y ajustes según

observaciones recibidas

5.0 2009-04-20 Informática Siglo 21 Ajustes al documento según observaciones recibidas.

6.0 2009-04-27 Informática Siglo 21 Se ajustó el documento de acuerdo a las observaciones de forma recibidas por parte del Programa Agenda de Conectividad y la Interventoría



Página 4 de 32

Tabla de Contenido Pág.

DERECHOS DE AUTOR ............................................................................... 7

CRÉDITOS .................................................................................................. 8

1 AUDIENCIA ......................................................................................... 9

2 INTRODUCCIÓN ................................................................................ 10

2.1 ALCANCE ........................................................................................... 10 2.2 OBJETIVO ......................................................................................... 10

3 VERSIONAMIENTO DE COMPONENTES ............................................ 12

3.1 COMPONENTES VERSIONABLES Y LÍNEAS BASE ................................... 12 3.2 ORGANIZACIÓN Y RESPONSABILIDADES ............................................. 13 3.3 IDENTIFICACIÓN DE COMPONENTES .................................................. 14 3.3.1 Reglas generales para nombramiento .............................................. 14 3.3.2 NOMBRAMIENTO DE LAS SOLICITUDES DE SERVICIO GEL-XML ........ 15 3.3.3 NOMBRAMIENTO DE LOS ELEMENTOS DE DATOS ............................ 15 3.3.4 NOMBRAMIENTO DE LOS ESQUEMAS XML ....................................... 17 3.3.5 NOMBRAMIENTO DE LOS DOCUMENTOS ASOCIADOS ...................... 19 3.4 CAMBIOS DE VERSIÓN EN COMPONENTES .......................................... 20 3.4.1 Cambios en elementos de dato ........................................................ 20 3.4.2 Cambios en esquemas XML de elementos de dato ............................ 20 3.4.3 Cambios en las definiciones de elementos de dato ............................ 21 3.4.4 Cambios en esquemas de biblioteca ................................................. 22 3.4.5 Cambios en el estándar GEL-XML ..................................................... 22 3.4.6 Cambios en dOCUMENTOS .............................................................. 23 3.5 POLÍTICAS Y PROTOCOLOS DE VERSIONAMIENTO .............................. 24 3.5.1 Protocolo de adaptaciones e incorporaciones de REPRESENTACION DE clasificaciones, nomenclaturas y/o listados. .................................................. 24 3.5.2 REGLAS Y Protocolos de construcción de clasificaciones, nomenclaturas y listados (en español y otros idiomas). ...................................... 25 3.5.3 Protocolo de movimiento de elementos de dato en capas. ................. 25 3.5.4 Protocolos de estudio de impacto derivados de la caducación de elementos de dato. .......................................................................................... 26



Página 5 de 32

3.5.5 Protocolo para tratamiento de cambios solicitados simultáneamente sobre componentes. ........................................................................................ 27 3.5.6 Protocolo de uso de elementos nuevos en proceso de definición. ....... 28 3.5.7 Protocolo a seguir cuando se encuentra un error en un elemento de dato del estándar. ........................................................................................... 28 3.5.8 Protocolo para el mantenimiento y soporte de elementos caducos. .... 29 3.5.9 Política de versionamiento para adaptadores. ................................... 29 3.5.10 Protocolo de manejo de excepciones (creación de políticas y protocolos no incluidas en este documento) ...................................................... 29 3.6 NOTIFICACIONES A CAMBIOS ............................................................. 30

4 APÉNDICES ....................................................................................... 31

4.1 APÉNDICE A: PALABRAS CLAVE A UTILIZAR PARA INDICAR NIVELES DE REQUERIMIENTO (RFC 2119) ........................................................................... 31 4.2 RESUMEN: ......................................................................................... 31



Página 6 de 32

Lista de Figuras

Figura 1. Lecturas recomendadas en GEL-XML ........................................................... 9 Figura 2. Organización requerida para versionamiento ................................................. 13 Figura 3. Codificación de documentos. ....................................................................... 20

Lista de Tablas

Tabla 1. Abreviaturas permitidas para el nombramiento de los identificadores ................ 17 Tabla 2. Criterios de codificación de acuerdo al proceso y el tipo de documento ............. 19



Página 7 de 32

DERECHOS DE AUTOR

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

A



Página 8 de 32

CRÉDITOS

a información y datos contenidos en la versión 1.0 del documento fueron elaborados por Informática Siglo 21 dentro del marco del proyecto Consultoría para la Administración y Gestión del estándar para el intercambio de

información GEL-XML. L



Página 9 de 32

1 AUDIENCIA

ste documento está dirigido al personal que se encuentre a cargo de la administración del estándar GEL-XML, en lo relacionado a la administración de los componentes constitutivos del estándar de intercambio de información GEL-

XML como lo son las solicitudes de servicio con su elementos de dato asociados. Adicionalmente aquellas entidades u organizaciones interesadas en participar en la iniciativa de Gobierno en Línea, encontrarán en este documento información que les permitirá una mejor comprensión de los componentes constitutivos del estándar de intercambio de información GEL-XML. Para una mejor comprensión se recomiendan las lecturas de los documentos que muestra la Figura 1

Figura 1. Lecturas recomendadas en GEL-XML

E



Página 10 de 32

2 INTRODUCCIÓN

EL-XML, Gobierno En Línea-eXtensible Markup Language, iniciativa suscrita dentro del ámbito de la Estrategia de Gobierno en Línea, se define como un lenguaje estándar para ser utilizado en los procesos de intercambio de

información, por parte de los diferentes actores que prestan y/o demandan trámites y/o servicios. Dentro de la política del Gobierno en Línea, GEL-XML tiene como objetivo facilitar la creación de interfaces estándar entre procesos y sistemas de información. Es habitual que los componentes del estándar (como los elementos de dato y documentos) sean ajustados, mejorados o corregidos. Para identificar esas modificaciones se utiliza el número de versión. El número de versión indica el avance de los cambios. Éste corresponde a números correlativos, y frecuentemente son dos cifras separadas por un punto. Por ejemplo, el paso de la versión 2 a la 3 de una aplicación suele conllevar cambios mayores, mientras que el paso de la versión 3.0 a la 3.1 indica cambios de menores, el cambio a la versión 4.0 implica cambios mayores. El documento consta de las siguientes secciones: Identificación de los componentes versionables, la organización requerida para el versionamiento, las reglas de nombramiento de los componentes, los cambios de versión en los componentes, las políticas y protocolos de versionamiento y las notificaciones a cambios.

2.1 ALCANCE

El presente documento de Versionamiento consigna las prácticas de cambio de versión de cada uno de los componentes del Estándar GEL-XML. Se consideran componentes del Estándar GEL-XML a los elementos de dato (incluidas las definiciones de elementos de datos y esquemas), los documentos (arquitectura de datos y guía de creación de esquemas) y el Estándar GEL-XML.

2.2 OBJETIVO

El objetivo general de este documento es establecer reglas, políticas y protocolos para el versionamiento de los componentes del Estándar de Intercambio de información GEL-XML. El documento permitirá:

o Identificar los componentes versionables del Estándar o Identificar las líneas base del Estándar

G



Página 11 de 32

o Identificar los cambios que ha tenido un componente a través del tiempo (evolución del componente).

o Establecer reglas para el nombramiento y versionamiento de los componentes del Estándar.

o Especificar registros que permitan establecer las relaciones de componentes del estándar en un determinado instante de tiempo mediante la definición de líneas base.

o Presentar la organización mínima requerida e involucrada con el versionamiento de los componentes.

o Especificar registros que permitan establecer el estado de un componente del estándar en un determinado instante de tiempo.

o Establecer los principales protocolos y políticas a seguir para el cambio (caducaciones y modificaciones) de alguno de los componentes del Estándar, incluyendo los componentes que sean afectados por estos cambios.



Página 12 de 32

3 VERSIONAMIENTO DE COMPONENTES

3.1 COMPONENTES VERSIONABLES Y LÍNEAS BASE

Una línea base es un conjunto de componentes (producto) o una especificación, en un periodo particular del tiempo, que han sido previamente creados, aprobados o modificados siguiendo un proceso formal. Dichos componentes sirven para un desarrollo posterior y pueden cambiarse a través de procedimientos formales.

Se han identificado los siguientes componentes dentro del estándar GEL-XML:

- Elementos de dato1 - Bibliotecas de esquemas - Documentos del estándar - Solicitudes de Servicio.

En conjunto, estos componentes generan las siguientes líneas base:

- Estándar GEL-XML, compuesto por: o Documento de Arquitectura de datos o Documento Guía de creación de esquemas o Conjunto de todos los elementos de dato. o Conjunto de total bibliotecas de esquemas: Las bibliotecas son esquemas

XML que incluyen otros esquemas XML que representan elementos de dato2,

- Conjunto de elementos relacionados con una Solicitud de Servicio o Elementos de dato o Bibliotecas de esquemas o Solicitud de Servicio (documental)

Las solicitudes de servicio son componentes dentro del estándar pero no son susceptibles de versionamiento debido a que la solicitud se recibe diligencia en un único momento y no es modificada durante el proceso de atención de las mismas. Para tener un mejor control sobre las líneas base y los componentes asociados a las mismas, se recomienda almacenar las líneas base del estándar, en un sistema de

1Un elemento de dato es un componente integrado por los metadatos – definición – y el esquema. Debido al número de elementos de dato, manejar versiones separadas para la definición y para el esquema seria una tarea compleja de administrar, solo se maneja una versión por elemento de dato. Esto hace que el esquema y la definición tengan la misma versión. En otros estándares apenas se maneja la versión del estándar y los elementos del estándar heredan dicha versión. 2 Debido a que el principal propósito de las bibliotecas es agrupar elementos de dato, no tienen metadatos que las definan.



Página 13 de 32

almacenamiento. Se RECOMIENDA realizar máximo una línea base por semana, pero solo cuando haya cambios. Junto con las líneas base y sus componentes se deberán tener los siguientes registros:

- Fecha de creación del componente, - Componentes vigentes de la línea base

Al tener los registros mencionados anteriormente, es posible indagar sobre los cambios que ha tenido el componente a través del tiempo. Se recomienda utilizar una herramienta informática para realizar los registros y consultas requeridas.

3.2 ORGANIZACIÓN Y RESPONSABILIDADES

La Figura 2 presenta la organización requerida relacionada con el versionamiento de los componentes del estándar de intercambio de información GEL-XML. Existen roles pertenecientes al Programa Agenda de Conectividad y otros al Operador.

Figura 2. Organización requerida para versionamiento

Existen tres roles por parte del Operador encargados de los cambios que se realizan a los componentes del estándar de intercambio de información - GEL-XML. Los roles responsables son:

• Coordinador de implementación e integridad o Consultor procesos o Consultor técnico

El rol asesor de integridad da soporte al coordinador de implementación e integridad, pero no tiene ninguna responsabilidad dentro de la administración de versiones ya que éstas son del coordinador de implementación e integridad.



Página 14 de 32

Existen dos roles por parte del Programa Agenda de Conectividad encargados de los cambios que se realizan a los componentes del estándar de intercambio GEL-XML. Los roles responsables son:

• Director de desarrollo o Consultor de Desarrollo

La Figura 2 muestra las dependencias de cada uno de los roles. Las responsabilidades de cada uno de los roles en cuanto a versionamiento de componentes se derivan del proceso de Gestión de la integridad3. A continuación se describen las responsabilidades para cada uno de los roles. Responsabilidades

• Coordinador de implementación e integridad: o Analizar el impacto de las solicitudes de modificación sobre los diferentes

componentes del estándar, incluido en cambio de versión de los componentes involucrados.

o Determinar las modificaciones a realizar sobre el componente

• Consultor procesos: o Realizar las modificaciones sobre el componente o Registrar los cambios sobre los componentes o Notificar sobre los cambios a los interesados

• Consultor técnico:

o Realizar las modificaciones sobre el componente o Registrar los cambios sobre los componentes

• Director de desarrollo:

o Aprobar los cambios a realizar sobre los componentes.

• Consultor de Desarrollo o Revisar los cambios a realizar sobre los componentes.

3.3 IDENTIFICACIÓN DE COMPONENTES

A continuación se presenta la forma de identificar y nombrar cada uno de los componentes versionables del estándar de intercambio GEL-XML.

3.3.1 REGLAS GENERALES PARA NOMBRAMIENTO A continuación se presentan reglas generales de uso de caracteres para el nombramiento de los componentes:

3 Para ampliación, consulte el documento de Procedimientos de Administración y gestión (DC-DS-AGC-0037_PROCED_DE_ADMON_Y_GESTION V1_3). Sección Codificación de los documentos



Página 15 de 32

- Se deberá utilizar en todos los casos la tabla de caracteres definida por la norma ISO 8859-1, que es el conjunto de caracteres para el estándar GEL-XML.

- Como regla general, todos los nombres de los componentes (archivo, elemento de dato, esquema) podrán usar caracteres que estén dentro del siguiente conjunto: A-Z, a-z y 0-9. No se permiten las vocales tildadas, letras con diéresis, y las letras ñ o Ñ.

- En caso que sea necesario el uso del guión (-) o el guión bajo (_) se deberá especificar en cada caso particular en la documentación del proyecto (e.g. Documento de Arquitectura de Datos). Por ejemplo cuando se utilice el nombre del estándar GEL-XML deberá llevar un guión en el medio. Para la separación de palabras de códigos de enumeraciones se deberá utilizar el guión bajo.

- En cuanto al nombramiento del componente “Documentos del estándar”, se deberán seguir las recomendaciones de la sección “3.3.5 Nombramiento de los documentos asociados” de este documento.

Dentro del documento se denominan caracteres especiales a todos los que están fuera del siguiente conjunto: A-Z, a-z, 0-9. Las siguientes secciones presentan las reglas de nombramiento por cada componente.

3.3.2 NOMBRAMIENTO DE LAS SOLICITUDES DE SERVICIO G EL-XML Para el código de la Solicitud de Servicio se utilizará un prefijo, consecutivo y año para las solicitudes del estándar GEL-XML. La nomenclatura de una solicitud de servicio es:

SS-GEL- [consecutivo-anual]-[año] Donde:

- DEBERÁ tener por prefijo SS-GEL (SS son las primeras letras de las palabras Solicitud y Servicio y GEL es acrónimo de Gobierno En Línea).

- A continuación DEBERÁ tener un consecutivo por cada solicitud de servicio dentro del año.

- Al final DEBE ir el año en el que fue recibida la solicitud de servicio. - Se utilizará como separador el guión medio, para una mejor lectura del significado

del código de la solicitud. - Ejemplo: SS-GEL-0005-2008 (Quinta Solicitud de Servicio Generada en el año

2008)

3.3.3 NOMBRAMIENTO DE LOS ELEMENTOS DE DATOS

Debido a que el nombre de los archivos de esquemas (que hacen parte de los componentes) involucran los nombres de algunos campos de la definición de los elementos de dato, a continuación se presentan las reglas de nombramiento de los



Página 16 de 32

campos “Elemento de dato” e “Identificador” de dicha definición. El nombramiento de los elementos de dato es definido en el documento de Arquitectura de datos.

3.3.3.1 IDENTIFICADOR “ELEMENTO DE DATO”

El identificador “Elemento de dato” es el nombre único asignado al concepto de dato para el cual la identificación, descripción, clasificación, valores permitidos, formato, validación, comprobación, usos, identificación de la entidad responsable y comentarios, son especificados por medio de un grupo de atributos. En la asignación del nombre se DEBE excluir todo tipo de artículo y/o preposición, así como realizarse en singular y tener en cuenta que:

• Si el elemento de dato es de tipo compuesto y representa el esquema a través del cual se requiere el registro, actualización, eliminación, consulta o listado de datos, el nombre DEBE iniciar por la abreviatura que representa una de las acciones mencionadas. Las abreviaturas son: Reg para registro, Act para actualización, Elm para eliminación, Lst para listado o consulta.

• Si el elemento de dato es de tipo compuesto y representa el esquema de entrada, al nombre se DEBE agregar el sufijo Ent.

• Si el elemento de dato es de tipo compuesto y representa el esquema de salida, al nombre se DEBE agregar el sufijo Sal.

3.3.3.2 METADATO “IDENTIFICADOR”

El metadato “Identificador” corresponde a una identificación única que se asigna al elemento de dato a partir del nombre del mismo. Para la construcción del identificador, se DEBE tener en cuenta:

1. El nombre PUEDE estar conformado por varias palabras tipo sustantivo, sin que la longitud del mismo no sobrepase los treinta (30) caracteres.

2. Si la longitud del nombre, sobrepasa los treinta (30) caracteres, se DEBE iniciar de derecha a izquierda a disminuir cada una de las palabras o términos que conforman el nombre en dos (2) caracteres.

3. Hacer uso del estándar para codificación tipo CAMEL, es decir, todos los caracteres del nombre DEBEN ir en minúscula exceptuando los caracteres de inicio a partir de la segunda palabra.

4. Abreviar algunas palabras que hacen parte del nombre, tal y como se indica a continuación:

PALABRA ABREVIATURA Código Cod Nombre Nom Identificador Id Número Num Abreviatura Abrev Registrar Reg



Página 17 de 32

PALABRA ABREVIATURA Actualizar Act Consultar Con Eliminar Eli Lista Lis Entrada Ent Salida Sal Alfabético Alf Alfanumérico AlfNum

Tabla 1. Abreviaturas permitidas para el nombramiento de los identificadores

El metadato “Identificador” NO DEBE contener caracteres especiales.

3.3.4 NOMBRAMIENTO DE LOS ESQUEMAS XML Dentro del estándar GEL-XML los esquemas se pueden clasificar de la siguiente manera:

- Esquemas de elementos de dato: Son las unidades de información del estándar GEL-XML. Éstos denotan elementos de dato de tipo simple y compuesto.

- Esquemas biblioteca: Son conjuntos de esquemas de elementos de dato. - Esquemas de mensajes: Son esquemas que definen los mensajes utilizados por

los servicios Web4, contienen elementos de dato y son una subclase de los esquemas de elementos de dato.

Cuando el esquema es almacenado en un archivo y/o la definición del elemento de dato, dicho nombre de archivo DEBE seguir las siguientes reglas:

- Nombre del archivo:

o Esquema del elemento de dato: El nombre del archivo corresponde a un prefijo y al metadato “Identificador” del elemento de dato. Si el elemento de dato es una enumeración DEBE tener el prefijo enum; si el elemento de dato corresponde a un grupo, el prefijo grupo, y si corresponde a otro tipo de dato, el prefijo tipo.

o Esquema de biblioteca: Si corresponde a un área de información, el nombre del archivo del esquema DEBE ser el mismo que el nombre del área de información a la que pertenecen los elementos de dato que agrupa. En caso de ser un proyecto, se utiliza el nombre del módulo dentro del proyecto. El nombre del esquema DEBE iniciar con mayúscula.

o Esquema de mensaje: El nombre del archivo corresponde al metadato “Identificador”.

4 Un servicio web (en inglés Web service) es un conjunto de aplicaciones o de tecnologías con capacidad para interoperar en la Web. Estas aplicaciones o tecnologías intercambian datos entre sí con el objetivo de ofrecer unos servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a través de la Web. Tomado de http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb el 16 de febrero de 2008.



Página 18 de 32

- Formato del nombre del archivo de los esquemas:

o El nombre del archivo debe ser en UCC (Upper Camel Case, todas las letras de inicio de palabra en mayúsculas) en caso que sea una biblioteca de elementos de dato (agrupación de elementos que están a un mismo nivel).

o El nombre del archivo debe ser en LCC (Lower Camel Case, todas las letras de inicio de palabra en mayúsculas excepto la primera palabra) en caso que sea un elemento de dato.

- Recomendación para el almacenamiento de esquemas:

o La ruta de almacenamiento del esquema para todas las capas dependerá de la versión del estándar, la capa y el área. Se DEBE almacenar de la siguiente manera:

� GEL-XML/[versión_del_estándar]/schemas/[capa]/[área ]

o Para los esquemas pertenecientes a las capas Uso Proyectos, Uso Internacional y Uso Plataforma de Interoperabilidad, dependerá de la versión del estándar, la capa, el proyecto ó estándar y el módulo. Se DEBERÁ almacenar así:

� GEL-XML/[versión_del_estándar]/schemas/[capa-proyectos]/[nombre_proyecto]/[nombre_módulo] o

� GEL-XML/[versión_del_estándar]/schemas/[capa-pdi]/[nombre-proyecto]/[módulo]

� GEL-XML/[versión_del_estándar]/schemas/[capa-internacional]/[nombre-estándar]/[módulo]

o Los esquemas de la capa Tipos de datos GEL-XML se almacenan en la raíz de la misma.

Ejemplo de ruta y nombre de un archivo de un elemen to de dato: /GEL-XML/1.0/schemas/Proyectos/Cancilleria/Certific ado/tipoDatoPersonal.xsd Ejemplo de ruta y nombre de un archivo de una bibli oteca de elementos (Las bibliotecas TIENEN el mismo nombre de su carpeta contenedora e inician con mayúscula): /GEL-XML/1.0/schemas/Proyectos/Cancilleria/Certific ado/Certificado.xsd Cuando el esquema ha sido modificado o eliminado, se recomienda crear una estructura paralela de almacenamiento con las rutas anteriormente propuestas en un directorio modificadoseliminados, por ejemplo:

modificadoseliminados/GEL-XML/1.0/schemas/Proyectos/Cancilleria/Certificado/



Página 19 de 32

En cuanto al nombre de los archivos de esquemas, se DEBERÁ agregar como sufijo la versión antigua o eliminada al nombre del archivo, precedido de la letra v y un guión. Por ejemplo:

tipoUsuarioSistemaSNR-v1.0.xsd

3.3.5 NOMBRAMIENTO DE LOS DOCUMENTOS ASOCIADOS El nombramiento de los documentos asociados se realizará de acuerdo con las políticas de calidad del Programa Agenda de Conectividad5. El nombramiento de los documentos se encuentra en la sección “Codificación de los documentos” del anteriormente citado documento, donde se deberá buscar la versión oficial. A continuación se presenta un extracto de dicho documento donde se define el nombramiento de los documentos. Para la codificación de los documentos se realizan los siguientes pasos:

o Definir macroproceso. o Identificar el proceso y escribir código de acuerdo a lo establecido en la columna

de CODIFICACIÓN PROCESO ubicada en la Tabla 1 Criterios de codificación de acuerdo al proceso y el tipo de documento.

PROCESO CODIFICACIÓN PROCESO

TIPO DOCUMENTO

CODIFICACIÓN TIPO

DOCUMENTO Direccionamiento DR Manual MA Investigación y Planeación IP Caracterización CR Articulación y Gestión AG Procedimiento PR Desarrollo DE Formato FM Operación OP Registro RG Apropiación AP Monitoreo y Evaluación ME Administrativa, Financiera y Jurídica AF Integridad IG Mantenimiento y Evolución MV

Tabla 2. Criterios de codificación de acuerdo al proceso y el tipo de documento

o Identificar el tipo de documento y codificar de acuerdo a lo establecido en la

columna de CODIFICACIÓN TIPO DOCUMENTO ubicada en la Tabla 1 Criterios de codificación de acuerdo al proceso y el tipo de documento.

o Indicar consecutivo numérico de acuerdo a la cantidad de documentos generados por el Sistema de Gestión de Calidad, los cuales son controlados por el Representante de la Dirección, por medio del Listado Maestro de Documentos.

5 Para más información ver el documento “Manual de Parametrización Documental” (AdCMEMA-004 Manual de parametrización documental)



Página 20 de 32

DR PR 001

MACROPROCESO PROCESO TIPO DOCUMENTO

CONSECUTIVOAdC DR PR 001

MACROPROCESO PROCESO TIPO DOCUMENTO

CONSECUTIVOAdC

Figura 3. Codificación de documentos.

o Agregar el nombre del documento seguido de su versión. Se pueden utilizar el carácter underscore (guión bajo) para separar las palabras del nombre. El nombre del documento puede ser resumido para evitar nombres de documentos largos.

Ejemplos de codificación son:

• GEL-IG-RG-001_Versionamiento_V1.0.doc • GEL-MV-RG-001_Arquitectura_Datos_V4.2.doc • GEL-MV-RG-002_Guia_Creacion_Esquemas_V3.6.doc

3.4 CAMBIOS DE VERSIÓN EN COMPONENTES

En esta sección se especifica como asignar los valores a la versión a cada componente. La versión de un componente está dada por dos números separadas por un punto por ejemplo M.n; donde M es la versión mayor y n la versión menor. Los cambios de versión de los componentes de estándar se definen a continuación.

3.4.1 CAMBIOS EN ELEMENTOS DE DATO

En la medida que el elemento de dato es componente atómico que DEBE estar integrado por los metadatos y el esquema, todo cambio sobre los metadatos o sobre el esquema genera un cambio en el elemento de dato como se describe a continuación.

3.4.2 CAMBIOS EN ESQUEMAS XML DE ELEMENTOS DE DATO Los siguientes cambios implican un cambio de versión menor en el elemento de dato:

• Adición de nuevos elementos XML opcionales o atributos opcionales. • Cambio en los atributos, de obligatorio a opcional. • Cambio de elementos XML cardinales de un viejo esquema [0..1] a nuevo

esquema [0..*]. • Cambio de elementos XML 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

GEL



Página 21 de 32

Los siguientes cambios implican un cambio de versión mayor:

• Cambio en los atributos de opcional a obligatorio. • 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 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.

La versión del elemento de dato y esquema DEBERÁ verse reflejada en el atributo versión al inicio del documento XML y en los metadatos del documento. La versión de la definición del elemento de dato DEBERÁ ser la misma que la versión del esquema que lo representa en la medida que el elemento de dato es componente atómico que DEBE estar integrado por los metadatos y el esquema. En ese orden de ideas, un cambio del esquema XML del elemento de dato implica un cambio en el elemento de dato.

3.4.3 CAMBIOS EN LAS DEFINICIONES DE ELEMENTOS DE DATO Todo cambio sobre la definición del elemento de dato (metadatos), modifica la versión del elemento de dato cuando afecta cambia el esquema. Si el cambio impacta el esquema, el número de la versión se modificará según la sección “CAMBIOS EN ESQUEMAS XML DE ELEMENTOS DE DATO”. Los cambios cosméticos (i.e. tildes, ortografía, forma) dentro de la definición, no son considerados como cambios. Tampoco se considera un cambio menor agregar un uso a la definición del elemento de dato. Se hacen las anteriores consideraciones debido a que se debe evitar modificar la especificación técnica y/o el número de la versión del elemento de dato, cuando los cambios sean mínimos y no afecten la compatibilidad entre versiones diferentes de los esquemas, lo anterior minimiza el número de versiones y permite tener un estándar de intercambio más estable.



Página 22 de 32

3.4.4 CAMBIOS EN ESQUEMAS DE BIBLIOTECA

Una biblioteca es el conjunto de elementos de dato que pertenecen a un mismo espacio de nombres. En la práctica la biblioteca es un esquema XML que actúa como índice para el acceso a los elementos de dato pertenecientes a ella. Un cambio de versión menor en la biblioteca se realiza cuando se conservan los elementos con respecto de la versión anterior. Hay un cambio de versión mayor cuando no se conservan los elementos. En cuanto al número de la versión de la biblioteca:

- Un esquema de biblioteca cambiará en versión menor cuando uno de sus elementos de dato cambie en versión mayor o cuando sea agregado un elemento de dato.

- Un esquema de biblioteca cambiará en versión mayor cuando sea eliminado un elemento de dato de la biblioteca

Los cambios de versiones menores de los esquemas de elementos de dato incluidos en las bibliotecas, no tienen impacto en las bibliotecas debido a que dichos esquemas son compatibles hacia atrás y en consecuencia las bibliotecas también son compatibles hacia atrás.

3.4.5 CAMBIOS EN EL ESTÁNDAR GEL-XML La versión mayor del estándar cambiará cuando: • Cuando exista un cambio estructural en la arquitectura de datos. Se define como

cambio estructural como: o Una modificación de la arquitectura de datos de forma que la afecte la mayoría

de los elementos de la arquitectura previa, cambiándolos de tal forma que ya no sean compatibles con la arquitectura anterior.

o La eliminación o inclusión de una capa o un área. o El cambio de las reglas de creación de elementos de dato.

• Cuando un cambio en la guía de creación de esquemas implique que al crear un esquema de un elemento de dato con la nueva guía, sea incompatible con los esquemas de los elemento de dato creados con la guía antigua.

La versión menor del estándar cambiará cuando: • Cuando los cambios de los artefactos de arquitectura y guía de creación de esquemas

no impacta sobre los elementos y/o los elementos son compatibles hacia atrás después del cambio de dichos artefactos.

La versión del estándar y los demás componentes se manejarán independientemente. En el caso que se genere un cambio que amerite una nueva versión del estándar, se deberá generar una línea base del estándar que incluya TODOS sus componentes ajustados según las modificaciones incluidas en el estándar.



Página 23 de 32

3.4.6 CAMBIOS EN DOCUMENTOS

Los documentos tienen cambios debido a la evolución registrada y requerida en el uso del Estándar de Intercambio de Información GEL-XML. Se pueden identificar documentos públicos y documentos de trabajo. Los documentos públicos, como su nombre lo dice, son documentos oficiales que han sido liberados para el público en general. Los documentos de trabajo (o versiones borrador) pueden partir de un documento público o ser totalmente nuevos y cambian de versión hasta que llegan a una madurez y/o estabilidad para ser públicos. La diferencia entre los documentos públicos y los documentos de trabajo es que estos últimos son solo conocidos al interior del organismo de gestión del estándar. Se DEBERÁ incluir una marca de agua en los documentos de trabajo con la palabra borrador para poderlo diferenciar de una versión liberada al público. Los cambios de documentos se reflejan en la modificación del valor de la versión mayor y la menor del documento. Según la sección 7 (Glosario) del documento “Manual de Parametrización Documental”:

“La Versión Mayor: Representa los cambios sustanciales (estructura, contenido, objetivo, alcance, descripción de actividades, etc.) que ha tenido el documento a través del tiempo. Se compone por un solo dígito el cual debe ser un número entero. Por ejemplo: 1, 2, 3. La Versión Menor: Representa los cambios o modificaciones mínimas del documento correspondientes a forma y estilo.”

Por ejemplo si un documento está en versión 3.0 y se hace necesaria una modificación de forma o estilo, la siguiente versión será la 3.1.Por el contrario, cuando el documento sufra un cambio en su estructura, se publicará en la siguiente versión mayor. En este caso será versión 4.0. Todos los cambios mínimos u omisiones en los documentos públicos o cualquier otro cambio sobre un documento generarán una nueva versión cuyo número será asignado según lo consignado en esta sección. Cuando un documento se hace público se debe garantizar lo siguiente:

1. Haber realizado una revisión para detectar y corregir errores ortográficos. 2. Haber realizado una revisión para detectar y corregir errores de forma. 3. Haber realizado una revisión para detectar y corregir errores de redacción. 4. Según la herramienta de edición de texto utilizada, eliminar comentarios y

controles de cambio generados durante la edición. 5. Revisión de la integridad del documento, es decir que lo que dice el documento

no se contradiga con lo publicado. Cuando se deban hacer precisiones sobre la información de un documento publicado, se recomienda crear documentos auxiliares donde se consignen los cambios. Cuando se realicen las modificaciones sobre los documentos principales los documentos auxiliares deberán integrarse al documento principal. Lo anterior evita realizar muchos cambios sobre los documentos principales o públicos.



Página 24 de 32

3.5 POLÍTICAS Y PROTOCOLOS DE VERSIONAMIENTO

A continuación se presentan las reglas generales y específicas sobre las acciones a tomar en los escenarios que implican cambios sobre los componentes del estándar GEL-XML. A no ser que se diga lo contrario, el organismo administrador del estándar de intercambio de información es el encargado de ejecutar y/o llevar a cabo las tareas incluidas en los protocolos. Las políticas y protocolos a abordar son las siguientes:

3.5.1 PROTOCOLO DE ADAPTACIONES 6 E INCORPORACIONES7 DE REPRESENTACION DE CLASIFICACIONES 8, NOMENCLATURAS 9 Y/O LISTADOS.

A continuación se presentan las reglas de inclusión de clasificaciones, nomenclaturas y/o listados:

1. Buscar si existe una clasificación sobre el mismo concepto a nivel internacional o nacional respaldada por una institución de normalización, de ser así SE DEBE incorporar la clasificación, nomenclatura y/o listado existente (según el paso 3) Se debe dar prioridad a clasificaciones nacionales10.

2. Buscar si existe una clasificación existente sobre el mismo concepto a nivel internacional en el idioma español, de ser así SE DEBE incorporar la clasificación, nomenclatura y/o listado existente en español (según el paso 3).

3. Incluir los códigos de la clasificación internacional y/o nacional (en caso de que existan) e incluir las descripciones de los códigos en español (en caso que existan).

4. Si las descripciones disponibles no se entienden o no están contextualizadas para Colombia se DEBE crear un elemento de dato con las descripciones contextualizadas para Colombia. Las adaptaciones deben ser respaldadas por un ente oficial.

5. NO SE DEBE modificar los códigos de las clasificaciones. Se debe dar prioridad a las clasificaciones utilizadas por el DANE ya que dichas clasificaciones se consideran como oficiales dentro de Colombia y el DANE realiza las respectivas adaptaciones al país.

6 Clasificaciones resultantes de modificar la estructura de una clasificación adoptada de tal forma que refleje las características económicas y sociales de un país. 7 Uso directo de un listado externo para cualificar objetos. 8 Agrupamiento de fenómenos u objetos, en conjuntos homogéneos, exhaustivos y mutuamente excluyentes, de acuerdo con criterios preestablecidos y en función del uso que tendrá la clasificación. 9 Asignación sistemática de nombres a cosas o un sistema de nombres o términos para cosas. 10 En Colombia el organismo rector de las clasificaciones es el DANE.



Página 25 de 32

3.5.2 REGLAS Y PROTOCOLOS DE CONSTRUCCIÓN DE CLASIF ICACIONES, NOMENCLATURAS Y LISTADOS (EN ESPAÑOL Y OTROS IDIOMA S).

A continuación se presentan las reglas de construcción de clasificaciones, nomenclaturas y/o listados en otros idiomas:

• En el caso de que no exista la clasificación dentro del estándar y se tenga la información tanto de la clasificación Internacional como la adaptada a Colombia, se incorporará al estándar la Clasificación adaptada a Colombia.

• Si la adaptación corresponde sólo a la descripción de ítems de la clasificación, se DEBERÁ definir un elemento de dato para el código de la clasificación en la capa de Uso Común y se define otro elemento de dato para la descripción del código en la capa de Uso Local. Esta separación de capas se hace debido a que no todas las descripciones aplican a nivel Común. Es posible tener diferencias en el uso del idioma, por lo tanto, la descripción en la capa de Uso Local solo aplicaría (sería entendible) para Colombia.

• Si la adaptación de la clasificación incluye modificaciones a los códigos, se DEBERÁ definir los elementos de dato para el código y la descripción en la capa de Uso Local.

• Si la definición del elemento de dato es almacenada en un archivo, un acrónimo de del idioma de la plantilla se pondrá como sufijo (basado en un listado estándar, por ejemplo ES-CO, EN-US, etc.) en el nombre del archivo, por ejemplo ES-CO o EN-US. Si no existe dicho sufijo se entiende que por defecto el idioma es español de Colombia.

• En el caso que el esquema corresponda a una codificación, éste tendrá las descripciones de los códigos en los idiomas que se hayan definido. Para el caso de los elementos de Dato de las capa de uso Común y Local PUEDEN ser inglés y español. En caso de hacer una modificación en las descripciones de una clasificación, nomenclatura y/o listado, la versión del esquema y de la definición del elemento de dato DEBE cambiar de versión menor.

• Las correspondencias11 entre las clasificaciones no se definirán dentro del estándar, ya que las correspondencias no son conceptos de intercambio dentro del estándar de intercambio GEL-XML.

Se debe preferir utilizar clasificaciones ya existentes en vez de crearlas debido a que facilita el intercambio con las Entidades que ya las están utilizando como también evita errores en la creación de las mismas.

3.5.3 PROTOCOLO DE MOVIMIENTO DE ELEMENTOS DE DATO EN CAPAS. Al mover un elemento de una capa o área se DEBE tener en cuenta: 1. Identificar los elementos de dato que requieren el elemento de dato a mover.

11 El término correspondencia aquí es utilizado como la relación de una categoría de una clasificación con dos o más categorías de una o varias clasificaciones. (http://www.dane.gov.co/files/nomenclaturas/glosario.pdf) Por ejemplo se puede tener una clasificación para actividad económica y otra para tipo de productos. Si la actividad económica es la agricultura tiene una relación (correspondencia) con productos como hortalizas.



Página 26 de 32

2. Consultar con los interesados (usuarios o creadores) de los elementos de dato que serán reubicados y los identificados en el punto 1, sobre la factibilidad de hacer el movimiento. Si no hay objeciones ir al punto 4.

3. Discutir, analizar y acordar sobre la factibilidad del movimiento del elemento de dato con los interesados, se deberán analizar los siguientes puntos:

a. Número de elementos afectados b. Valor que daría al estándar mover el elemento. c. Impacto sobre los desarrollos de los interesados (económico y de tiempo)

4. Si el movimiento es aprobado, se realiza el numeral 4.a, Si el movimiento no es aprobado se realiza el numeral 4.b

a. La solicitud será generada por el organismo según las decisiones tomadas en el punto 3 para ajustar los elementos de dato que se hagan necesarios.

b. La solicitud de servicio se analizará para la siguiente versión mayor del estándar de Intercambio, el análisis se realizará según lo mencionado en el punto 3.

Se la da facultad al Organismo de Administración y Gestión del estándar GEL-XML de generar la solicitud del punto 4.b, debido a que por experiencia las entidades pueden tardar en enviar las solicitudes modificación sobre los elementos de dato.

3.5.4 PROTOCOLOS DE ESTUDIO DE IMPACTO DERIVADOS DE LA CADUCACIÓN DE ELEMENTOS DE DATO.

Para la caducación de un elemento de dato se DEBERÁN seguir los siguientes pasos:

1. El solicitante DEBERÁ explicar amplia y claramente los motivos por los cuales se solicita la caducación de un elemento de dato. Si el motivo de la caducación es externo al organismo y elimina el concepto representado por el elemento de dato, como una nueva ley o una resolución o tiene un vicio de creación (i.e. no cumple con la arquitectura de datos en la que fue creado), se puede continuar con el proceso obviando el paso 4.

2. El elemento de dato DEBE estar en estado publicado, de lo contrario la caducación no aplica.

3. Identificar qué elementos de dato se verán afectados con la caducación. 4. Citar a una reunión con los interesados en el elemento de dato (usuarios,

creadores y colaboradores), para llegar a un consenso sobre las implicaciones de la caducación del elemento de dato y definición del un elemento sustituto si aplica. Los puntos a tener en cuenta son: a. Número de elementos afectados b. Valor que daría al estándar caducar el elemento de dato. c. Impacto sobre los desarrollos de los interesados (económico, esfuerzo y de

tiempo). 5. En caso de lograr un consenso entre los usuarios, creadores y colaboradores,

se DEBERÁ radicar una solicitud de servicio, por parte de los interesados, para realizar las correspondientes creaciones y/o modificaciones a los elementos de dato afectados identificados en el paso 3. La caducación no podrá ser efectiva hasta que todos los elementos de dato involucrados sean modificados.



Página 27 de 32

6. Si no es posible lograr un consenso entre los usuarios, creadores y colaboradores de los elementos a caducar (paso 4), la solicitud será generada por el organismo administrador del estándar.

7. El elemento caducado será soportado hasta lo que ocurran una de las siguientes situaciones: a. Ocho meses* después de la caducación b. En el caso de existencia de una ley o resolución que soporte la caducación,

hasta la fecha de entrada en vigencia de la misma. * Los ocho meses corresponderían al tiempo necesario para hacer que las entidades conozcan los cambios y hagan los ajustes en las soluciones. Suponiendo en promedio un mes en cada etapa del desarrollo (levantamiento requerimientos, análisis, diseño, desarrollo, pruebas, implantación), y un mes de holgura.

3.5.5 PROTOCOLO PARA TRATAMIENTO DE CAMBIOS SOLICIT ADOS SIMULTÁNEAMENTE SOBRE COMPONENTES.

Si una Solicitud de Servicio genera cambios sobre un componente del estándar (especialmente elementos de dato), hasta que esta solicitud no finalice, ninguna otra Solicitud de Servicio podrá modificar los componentes asociados a la primera solicitud. De no tener esta restricción podrían generarse versiones simultáneas de un mismo componente, produciendo dificultades en la administración y evolución de cada uno. Un componente NO DEBE estar incluido en una Solicitud de Servicio (de modificación) en curso para poder ser modificado. Por lo tanto, si una nueva solicitud de servicio contiene un cambio sobre un elemento de dato DEBE esperar a que la solicitud de servicio en curso finalice. En conclusión, en cuanto a las modificaciones sobre el mismo componente, la primera solicitud en entrar es la primera solicitud en salir. Las solicitudes de servicio en estado "Aplazado12" no se consideran solicitudes en curso por lo que para efectos de este protocolo toda solicitud "aplazada" se considera como no existente o "Cerrada". Si una solicitud "concurrente" sale de un estado "Aplazado" esta debería reiniciarse desde la etapa de conceptualización. La solicitud aplazada se reinicia en la etapa de conceptualización porque es en esa etapa en donde se decide el trabajo que se va realizar sobre los componentes. Siempre que se reinicie una solicitud de servicio debe volver a la etapa de conceptualización debido a que PUEDEN presentarse cambios en los componentes afectados por la solicitud, y se requiere analizar nuevamente el trabajo a realizar.

12 Se considera una Solicitud de Servicio como aplazada cuando administrativamente se suspenden las actividades programadas sobre dicha solicitud.



Página 28 de 32

3.5.6 PROTOCOLO DE USO DE ELEMENTOS NUEVOS EN PROCESO DE DEFINICIÓN.

Como regla general las solicitudes de servicio en proceso DEBEN utilizar solo elementos de dato en estado publicado. Los elementos de dato asociados a una Solicitud de Servicio de modificación o creación (modificaciones o creaciones) PUEDEN ser utilizados por otros elementos dentro de la misma solicitud. NO DEBEN utilizarse elementos de dato en proceso de creación o en proceso de modificación porque no se conoce el resultado final de la modificación o creación. Si se llega a utilizar uno de los elementos de dato, es posible que cambie y el uso del mismo no serviría para el propósito que inicialmente fue pensado.

3.5.7 PROTOCOLO A SEGUIR CUANDO SE ENCUENTRA UN ERR OR EN UN ELEMENTO DE DATO DEL ESTÁNDAR.

Se pueden identificar los siguientes tipos de errores en el estándar:

- Omisión de la especificación (funcional y técnica): El elemento de dato no cumple a cabalidad con la guía de creación de esquemas y/o la arquitectura de datos (vigentes).

- Error funcional: La definición funcional del elemento de dato se realizó de una manera errónea.

- Error técnico: El esquema XML no refleja la conceptualización y/o tiene errores de XML.

- Error de forma: Existe un error que no afecta el uso del elemento de dato. Al encontrar algún error de los anteriormente mencionados dentro de un elemento de dato del estándar, se DEBERÁ generar una solicitud de servicio de modificación conceptual y/o técnica. Se identifican los siguientes escenarios:

1. Los usuarios del elemento de dato serán informados sobre el error según lo descrito en la sección “NOTIFICACIONES A CAMBIOS”.

2. En el caso que el elemento de dato tenga cualquier error y nadie lo utilice se DEBERÁ generar una nueva versión corregida del elemento de dato.

3. En el caso que el elemento de dato tenga un error funcional se DEBE generar

una solicitud de servicio para generar una nueva versión corregida del elemento de dato.

4. En el caso que el elemento de dato tenga un error técnico y/o de omisión de la especificación, se debe generar una nueva versión corregida del elemento de dato, que los interesados DEBEN utilizar. Los interesados serán informados según lo descrito en la sección “NOTIFICACIONES A CAMBIOS”.



Página 29 de 32

5. En el caso que el elemento de dato tenga un error de forma se DEBE generar una nueva versión corregida del elemento de dato y los interesados serán informados según lo descrito en la sección “NOTIFICACIONES A CAMBIOS”.

Se DEBE realizar la corrección de errores sobre los elementos en el menor tiempo posible para generar confianza del entandar en las Entidades y para facilitar su uso.

3.5.8 PROTOCOLO PARA EL MANTENIMIENTO Y SOPORTE DE ELEMENTOS CADUCOS.

Ningún elemento en estado “Caducado” tiene mantenimiento. Sin embargo, si existe una entidad que utilice el elemento de dato y dicho elemento tiene un error técnico, el elemento debe ser mantenido durante un periodo de ocho meses a partir de la fecha de caducación. Se hace mantenimiento sobre los elementos caducos que cumplan con la anterior regla, debido a los impactos que pueden tener sobre los desarrollos de los usuarios del estándar de intercambio de información GEL-XML.

3.5.9 POLÍTICA DE VERSIONAMIENTO PARA ADAPTADORES. Al estar los adaptadores incluidos dentro de esquemas previamente creados, el número de versión de los adaptadores incluye la versión mayor y menor del esquema en donde se encuentran. El número de versión del adaptador tendrá un tercer nivel adicional al del elemento de dato. El tercer nivel de la versión del adaptador, aumentará en uno por cada cambio que sufra el adaptador. Por ejemplo, si la versión del elemento de dato es 1.0 la versión del adaptador será 1.0.0, si el adaptador sufre un cambio pero no el elemento de dato, la versión del adaptador será 1.0.1, si la versión del elemento de dato cambia a 1.1, la versión del adaptador será 1.1.0. Es importante considerar que el tercer nivel del número de la versión del adaptador inicia en cero cada vez que cambia la versión del elemento de dato. Se crea un tercer nivel de versión en los adaptadores a mantener para facilitar su versionamiento y tener trazabilidad entre el adaptador y el esquema del elemento de dato.

3.5.10 PROTOCOLO DE MANEJO DE EXCEPCIONES (CREACIÓN DE POLÍTICAS Y PROTOCOLOS NO INCLUIDAS EN ESTE DOCUMENTO)

Si existe una situación que requiera una política no definida dentro de este documento, se DEBERÁ crear la política e incluirla dentro del presente documento, siguiendo el “Procedimiento de modificaciones de componentes del estándar GEL-XML”. Toda política y/o protocolo deberá tener:

• Un componente que genera o sobre el cual recae una acción • Un evento sobre un componente



Página 30 de 32

• Una acción a realizar sobre el componente.

3.6 NOTIFICACIONES A CAMBIOS

A continuación se presenta la forma de notificación de los cambios de los componentes del Estándar de Información GEL-XML en el proceso. Como regla general se DEBE notificar el cambio de componente en versiones activas del mismo componente o a los componentes que involucre el cambio. La notificación se realizará siempre a todos los usuarios del estándar. A continuación se relaciona las notificaciones que DEBEN ser realizadas, cuando existe un cambio en uno de los componentes.

• Estándar GEL-XML: Se informará cuando se libere una nueva versión, a todos los usuarios del estándar.

• Solicitudes de servicio GEL-XML: Se informará al solicitante cuando:

o La solicitud cambie de estado o Sea necesaria una respuesta del solicitante o Según lo requiera el proceso de la solicitud

• Elementos de dato (Esquemas XML y Bibliotecas de esquemas y definiciones

de elementos de dato): Se informará cuando sea publicada una nueva versión del elemento de dato, a los usuarios del estándar.

• Otros componentes: Se informará a través del portal.

Toda notificación DEBERÁ tener el nombre y la versión del componente cambiado, la fecha de cambio y el lugar en donde se puede consultar la nueva versión. Se DEBERÁ utilizar el portal del estándar GEL-XML, como canal primario, cuando se requiera informar al público en general. En caso contrario PODRÁ ser a través de correo electrónico u otro medio que permita entregar la información. El uso de portal no implica que no se puedan utilizar otros medios adicionales de comunicación.



Página 31 de 32

4 APÉNDICES

4.1 APÉNDICE A: PALABRAS CLAVE A UTILIZAR PARA INDI CAR NIVELES DE

REQUERIMIENTO (RFC 2119)

Network Working Group S.Bradner Request for Comments: 2119 Harvard University BCP: 14 Marzo 1997 Categoría: Mejor práctica actual Palabras clave a utilizar en RFC para indicar Niveles de Requerimiento. ESTATUS DE ESTE MEMORANDUM: Este documento especifica una mejor práctica actual de Internet para la comunidad Internet, y solicita su discusión y sugerencias para posibles mejoras. La distribución de este memorándum es ilimitada.

4.2 RESUMEN:

En muchos documentos de seguimiento estándar se usan varias palabras para indicar los requerimientos de la especificación. Estas palabras a menudo están en mayúsculas. Este documento define cómo DEBERÍAN ser interpretadas estas palabras en documentos IETF. Los autores que sigan estas instrucciones DEBERÍAN incorporar esta frase cerca del principio de sus documentos: Las palabras claves "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 2119. Nótese que la contundencia de estas palabras está modificada por el nivel de requerimiento del documento en el que son usadas.

1. DEBE: esta palabra, o los términos "REQUERIDO", "OBLIGATORIO " o "DEBERÁ", significa que la definición es un requerimiento insoslayable de la especificación.

2. NO DEBE: esta frase, o la frase "NO DEBERÁ ", significa que la definición es una

prohibición insoslayable de la especificación.

3. DEBERÁ : esta palabra, o el adjetivo "RECOMENDADO", significa que pueden existir razones válidas en determinadas circunstancias para ignorar un elemento



Página 32 de 32

determinado, pero que la totalidad de las consecuencias DEBEN ser comprendidas y cuidadosamente sopesadas antes de elegir otros derroteros.

4. NO DEBERÁ : esta frase, o la frase "NO RECOMENDADO", significa que pueden

existir razones válidas en determinadas circunstancias en las que el comportamiento en particular sea útil o incluso aconsejable, pero que la totalidad de las consecuencias DEBEN ser comprendidas y cuidadosamente sopesadas antes de implementar cualquier comportamiento descrito bajo esta etiqueta.

5. PUEDE: esta palabra, o el adjetivo "OPCIONAL ", significa que un elemento es

realmente opcional. Un proveedor puede elegir incluir el elemento porque un mercado en particular lo necesite o porque el proveedor sienta que realza el producto aunque otro proveedor pueda omitir el mismo elemento. Una implementación que no incluya una opción determinada DEBE estar preparada para interoperar con otra implementación que incluya la opción, aunque quizá con reducida funcionalidad. En el mismo orden de cosas, una implementación que incluya una opción en particular DEBE estar preparada para interoperar con otra implementación que no incluya la opción (excepto, por supuesto, para la característica que aporte la opción).

6. Guía de uso de estos imperativos: los imperativos del tipo definido en este

memorando DEBEN ser usados con cuidado y con mesura. En particular, sólo DEBEN ser utilizados donde sea realmente necesario para la interoperación o para limitar un comportamiento potencialmente dañino (por ejemplo, limitando retransmisiones). Esto es, no DEBEN ser usados para intentar imponer un método concreto a los implementadores cuando el método no sea necesario para la interoperabilidad.

7. Consideraciones de seguridad: estos términos se utilizan normalmente para

especificar comportamientos con implicaciones de seguridad. Los efectos sobre la seguridad de no implementar un DEBE o DEBERÍA , o hacer algo que la especificación dice NO DEBE o NO DEBERÍA ser hecho, pueden ser muy sutiles. Los autores de documentos DEBERÍAN tomarse su tiempo para elaborar las implicaciones de seguridad respecto a no seguir recomendaciones o requerimientos, ya que la mayoría de los implementadores no tienen el beneficio de la experiencia y de la discusión que produjo la especificación.

8. Agradecimientos: las definiciones de estos términos son una amalgama de las

definiciones tomadas de numerosos documentos RFC. Además, se han incorporado sugerencias de numerosas personas incluyendo a Robert Ullmann, Thomas Nartenm Neal McBurnett, y Robert Elz.

DIRECCIÓN DEL AUTOR: Scott Bradner Harvard University 1350 Mass. Ave. Cambridge, MA 02138 Phone - +1 617 495 3864 Email - [email protected] Traducción: José M. Cainzos [email protected] SEVILLA –SPAIN.

GEL-XML, LENGUAJE ESTÁNDAR DE INTERCAMBIO...

Documents

Transcript of GEL-XML, LENGUAJE ESTÁNDAR DE INTERCAMBIO...