ESQUEMAS XML. Si se consiguen especificar estas condiciones, los valores de los componentes de localización podrán ser tales como:

Transcripción

1 ESQUEMAS XML. Aunque el concepto de DTD forme parte de la Recomendación XML,hay que resaltar que una DTD se restringe a describir la estructura del documento, presentando importantes limitaciones a la hora de definir el contenido permitido de los elementos, para lo que se basa prácticamente en el uso de PCDATA. Para comprobar la necesidad de llegar a concretar más la estructura de un documento, de lo que se hace una DTD, supóngase que en un documento relacionado con Geografía se quiere usar el elemento localización y que por razones fáciles de entender, se requiere que para que sea válido deba cumplir condiciones como las siguientes : 1.Estar compuesto por : longitud, latitud y un error asociado a la medida. 2.Los elementos latitud y longitud deben tener seis cifras decimales y unos rasgos respectivos de, 90 a +90, y 180 a El error en la localización debe ser un entero no negativo. Si se consiguen especificar estas condiciones, los valores de los componentes de localización podrán ser tales como: <localización> <latitud> </latitud> <longitud> </longitud> <incertidumbre unidad= metros >2</incertidumbre> </localización> Para asegurar que restricciones como las del ejemplo se cumplen, es importante contar con un mecanismo que asegure la validez de los correspondientes valores, algo que una DTD no puede hacer. Por ello y con el objeto de superar estas carencias surgió la idea de generalizar las DTDs utilizando la propia sintaxis XML a la hora de definir y validar las características de Esquemas XML son la alternativa seguida actual haya otras opciones ( como RelaxNG ) los Esquemas XML son la alternativa seguida por W3C para superar la función de las DTDs y sobre la que trabajan los desarrolladores actuales, lo que significa que en estos momentos son multitud los Esquemas XML utilizados en los más diversos campos. Juan Manuel Alcázar Donaire 1/28

2 Por tanto, para validar un documento XML se recurre a otros documentos llamados Esquemas XML; la idea perseguida es contar con un vocabulario XML que permita expresar las reglas que estructuran los documentos XML utilizados en una tarea determinada, de forma que a partir de los Esquemas se puedan definir unos documentos instancia que usen este vocabulario. Por ello, la aproximación de los Esquemas dentro de la práctica del XML es doble : La mejora de las funcionalidades de las DTD proporcionando un nuevo método de validación. La abstracción de la estructura de un documento determinado ya existente, al objeto de poder aplicar esta misma estructura a otros documentos, que se convertirán en documentos instancia del documento Esquema. En consecuencia, un Esquema especifica una clase de documentos, que interesa tener bien especificados dentro de una determinada tarea, con el objetivo de poder obtener documentos instancia o formularios ajustados a la aplicación; ello significa especificar tanto la estructura de los documentos instancia como el tipo de dato de cada elemento/atributo, de forma que por un lado, se dicen cosas del tipo este elemento contiene tales subelementos, que a su vez contiene estos otros, etc., y otras del tipo este elemento es un entero cuyo rango va de 90 a +90. Los requisitos perseguidos por los Esquemas son : a)usar la sintaxis XML y como tales documentos XML, ajustarse a su vez a las DTDs que describen la estructura de un Esquema, estando obviamente estas DTDs ligadas al analizador que valida Esquemas. b)disponer, a la hora de elaborar determinados documentos, de un documento XML que evoque a un Esquema que interesa declarando al nuevo documento como válido si está de acuerdo con el Esquema y en caso contrario el analizador que lo declare no válido, como si se trabajara con una DTD. c)tener la máxima libertad para soportar tipos de datos a la hora de especificar elementos y atributos. Adelantemos que mientras una DTD soporta 10 tipos de datos, los Esquemas tienen predefinidos 44 y lo que es más importante, capacidad para derivar todos los que se puedan necesitar. d)recurrir y utilizar espacios de nombres, cosa no posible en una DTD. e)tener la posibilidad de crecimiento de los documentos Esquemas a medida que se tengan que modificar distintos aspectos. f)máxima flexibilidad para poder acceder a ellos desde la Web. En la actualidad son muchas las organizaciones e individuos dedicados a la creación de Esquemas para un gran número de sectores : financiero, científico médico, edición, etc. Juan Manuel Alcázar Donaire 2/28

3 4.1 De una DTD a un Esquema Al único objeto de introducir la evolución desde una DTD a un Esquema, consideremos un ejemplo de DTD, que identificamos por libreria.dtd : <!ELEMENT Libreria (Libro+)> <!ELEMENT Libro (Titulo,Autor,Fecha,ISBN,Editorial)> <!ELEMENT Titulo (#PCDATA)> <!ELEMENT Autor (#PCDATA)> <!ELEMENT Fecha (#PCDATA)> <!ELEMENT ISBN (#PCDATA)> <!ELEMENT Editorial (#PCDATA)> A partir de ella veamos su correspondiente sintaxis como Esquema : librería.xsd. Como se observa aparece un prólogo como en todo documento XML y a continuación los elementos XML equivalentes a los distintos elementos de libreria.dtd : <?xml version= 1.0 encoding= UTF 8?> <xsd:schema xmlns:xsd= targetnamespace= xmlns= elementformdefault= qualified > <xsd:element name= Libreria > <xsd:complextype> <xsd:sequence> <xsd:element ref= libro minoccurs= 1 maxoccurs= unbounded /> </xsd:sequence> </xsd:complextype> </xsd:element> Las siete últimas líneas equivalent a <!ELEMENT Libreria (Libro+)> <xsd:element name= Libro > <xsd:complextype> <xsd:sequence> <xsd:element ref= Titulo minoccurs= 1 maxoccurs= 1 /> <xsd:element ref= Autor minoccurs= 1 maxoccurs= 1 /> <xsd:element ref= Fecha minoccurs= 1 maxoccurs= 1 /> <xsd:element ref= ISBN minoccurs= 1 maxoccurs= 1 /> <xsd:element ref= Editorial minoccurs= 1 maxoccurs= 1 /> </xsd:sequence> </xsd:complextype> </xsd:element> Juan Manuel Alcázar Donaire 3/28

4 Estas últimas líneas equivalen a : <!ELEMENT Libro (Titulo,Autor,Fecha,ISBN,Editorial)> <xsd:element name= Titulo type= xsd:string /> Equivale a <!ELEMENT Titulo (#PCDATA)> <xsd:element name= Autor type= xsd:string /> Equivale a <!ELEMENT Autor (#PCDATA)> <xsd:element name= Fecha type= xsd:string /> Equivale a <!ELEMENT Fecha (#PCDATA)> <xsd:element name= ISBN type= xsd:string /> Equivale a <!ELEMENT ISBN (#PCDATA)> <xsd:element name= Editorial type= xsd:string /> Equivale a <!ELEMENT Editorial (#PCDATA)> 4.2 De un documento XML a un Esquema Los Esquemas se elaboran con el objetivo de obtener un patrón y ello muchas veces se hace a partir de un determinado documento XML ya usado y probado, con el objetivo de tratar de definirlo con la máxima generalidad para que otros documentos se adapten al Esquema obtenido y el documento que ha servido de muestra acabe siendo una instancia del Esquema obtenido y el documento que ha servido de muestra acabe siendo una instancia del Esquema obtenido. Supóngase el documento XML miatlas.xml, a partir del cual se pretende definir un Esquema del que sea una instancia, cuyo contenido sea : <?xml version= 1.0 enconding= ISO ?> <Atlas> <Pais> <Nombre>Colombia</Nombre> <Capital>Santa Fe de Bogota</Capital> Juan Manuel Alcázar Donaire 4/28

5 <Poblacion> </Poblacion> <Extension> </Extension> </Pais> <Pais> <Nombre>España</Nombre> <Capital>Madrid</Capital> <Poblacion> </Poblacion> <Extension>505957</Extension> </Pais> <Pais> <Nombre>Francia</Nombre>. </Pais>. </Atlas> La DTD correspondiente a este documento es : <!ELEMENT Atlas(Pais)> <!ELEMENT Pais(Nombre,Capital,Población,Extension)> <!ELEMENT Nombre (#PCDATA)> <!ELEMENT Capital (#PCDATA)> <!ELEMENT Poblacion (#PCDATA)> <!ELEMENT Extension (#PCDATA)> Y el resultado de generalizar miatlas.xml a un Esquema XML ( atlas.xsd ) : <?xml version= 1.0 enconding: UTF 8?> <xs:schema xmlns:xs= elementformdefault= qualified > <xs:element name= Atlas > <xs:complextype> <xs:sequence> <xs:element ref= Pais mioccurs= 1 maxoccurs= unbounded /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name= Pais > <xs:complextype> <xs:sequence> <xs:element ref= Nombre /> <xs:element ref= Capital /> <xs:element ref= Poblacion /> <xs:element ref= Extension minoccurs= 0 /> Juan Manuel Alcázar Donaire 5/28

6 </xs:sequence> </xs:complextype> </xs:element> <xs:element name= Nombre type= xs:string /> <xs:element name= Capital type= xs:string /> <xs:element name= Poblacion type= xs:int /> <xs:element name= Extension type= xs:int /> </xs:shema> Para usar este esquema atlas.xsd dentro del documento inicial miatlas.xml habría que modificar su prólogo para reverenciarlo adecuadamente, de forma que ahora sus primeras sentencias serían de la forma : <?xml version= 1.0?> <Atlas xmlns = xmlns:xsi= instance xsi:shemalocation= > 4.3Conceptos de Esquemas XML Su elemento raíz es shema, que incorpora distintos espacios de nombres y atributos, de forma que los elementos y tipos de datos usados pertenecen al espacio de nombres declarado en : xmlns:xsd= cuyo prefijo es xsd ( XML Shema Definition ), aunque también se suele usar xd. Por medio de targetnamespace se indican los elementos específicos de un determinado espacio de nombres usado por el Esquema, pudiéndose usar un espacio de nombres por defecto. Con el uso de Esquemas se produce un doble proceso de validación : un documento XML se valida respecto al Esquema y éste a su vez es un documento que se valida de acuerdo con las reglas del analizador de Esquemas. Los elementos para declarar elementos y atributos son element y attribute. Como veremos, con la excepción de los llamados componentes anónimos, estos elementos y atributos tienen al menos un nombre y un tipo de dato debidamente definidos. Cada ELEMENT de la DTD pasa a ser un elemento element en el Esquema y en analogía con los elementos de una DTD, se usa el tipo element de la forma : <xsd:element name= nombre type= tipo /> Declaraciones y Definiciones Juan Manuel Alcázar Donaire 6/28

7 Es importante se señalar que en un Esquema XML las declaraciones de elementos, atributos, etc. y la definición de los tipos de dato no se diferencian entre ellos, de forma que para definir la estructura y tipos de datos que soporta documento instancia, se usan los elementos simpletype ( contiene sólo datos y ningún elemento hijo ) y complextype ( contiene además elementos hijo y atributos ). Dicho lo anterior, un Esquema es un documento XML que incorpora declaraciones y definiciones, de forma que se declaran los elementos y atributos que se van a representar en el documento instancia, y se definen las componentes que van a ser objeto de uso y no de representación, como son los tipos de datos. Una vez declarados, los elementos y atributos pueden ser objeto de referencias dentro de distintos contextos o ámbitos, para lo que sus nombres respectivos son básicos y de esta forma, los documentos instancia pueden reverenciarlos todas las veces que los necesiten. Así, si se tiene un elemento de nombre numerotelefono con un tipo de dato cadena : <xsd:element name= numerotelefono type= xsd:string > cada vez que se quiera refernciar este elemento se recurre al atributo ref de element y se escribe : <xsd:element ref= numerotelefono /> Puesto que en un documento instancia todo elemento o atributo declara ser instancia de un determinado tipo, el elemento numerotelefono ya tiene nombre y tipo, de forma que al referenciar numerotelefono en el documento instancia, éste reclama automáticamente que es una instancia de él, con lo que se puede escribir sin problemas: <numerotelefono> </numerotelefono> 4.5 Global vs. Local En un Esquema, los elementos, los atributos y la mayoría de sus componentes pueden ser globales o sólo estar referidos a otros componentes del mismo, por ello habla de panorámica global, ( se pueden referenciar en cualquier sitio del Esquema ) o local ( su uso queda limitado a una parte del contenido del Esquema ). Juan Manuel Alcázar Donaire 7/28

8 Un componente global puede referenciar a componentes globales de uno o más espacios de nombre y utilizarse en cualquier documento instancia del Esquema, cosa que no tiene sentido en el caso local. Sólo son elementos y atributos globales los que son hijos del elemento raíz schema, y en consecuencia, su referencia en el documento instancia aparece en el nivel superior. Dos consecuencias de la diferencia entre la panorámica global y local son : a)las declaraciones no pueden contener referencias, y por ello deben identificar directamente tanto tipos simples como tipos complejos ( como veremos ello significa que las declaraciones globales no pueden contener el atributo ref y deben usar el atributo type ). b)las restricciones de cardinalidad sólo pueden estar en las declaraciones locales, ya que en una perspectiva global, el número de apariciones es obviamente incontrolable. A efectos prácticos, la distinción principal entre componentes globales y locales radica en que sólo los primeros pueden reverenciarse ( o reusarse ) con lo que un elemento o atributo local acaba siendo invisible para el resto del Esquema, y en cada caso hay que decidir en función de esta característica para recurrir a una u otra panorámica. 4.6 Espacios de nombres en Esquemas Una diferencia importante entre las DTDs y Esquemas reside en que éstas, como tales documentos XML, pueden usar vocabularios asociados a espacios de nombres, con lo que se abre la posibilidad de marcar la diferencia entre elementos que compartan el mismo nombre pero no los mismos significados y viceversa. Considérese el recurso código postal, que en España es de la forma ddddd ( d representa un dígito ), mientras que en Estados Unidos es : CC ddddd ( donde CC identifica el Estado); ambos obedecen a un mismo concepto pero presentan distintos contenidos. Para superar este problema hay que proporcionar un espacio de nombre para cada país y asociarle un prefijo a cada uno de ellos. Gracias a que un Esquema puede verse tanto como una colección de definiciones de tipo, como de declaraciones de elementos, se tiene la posibilidad de indicar a qué espacio de nombres particular pertenecen los nombres que se vayan a usar, lo que permite distinguir entre definiciones y declaraciones pertenecientes a diferentes vocabularios. Así, con el uso de los espacios de nombres distintos, se puede distinguir entre los distintos códigos postales, ya que para resolver el problema planteado basta con una declaración para el código de cada Juan Manuel Alcázar Donaire 8/28

9 país concreto que se vaya a utilizar en cada documento instancia. En otras palabras bastará con cambiar el espacio de nombres para mantener la validez de la aplicación con la que se trabaja. 4.7 Papel de los Espacios de Nombres En un Esquema aparece una diversidad de espacios de nombres, con funciones distintas en cada caso; en el primer ejemplo, se observa que en atlas.xsd aparecen los siguientes : Xmlns:xsd= indica que los elementos y tipos de los datos usados ( schema, element, complextype, sequence, string, bolean, integer ) provienen del espacio de nombres targetnamespace= : indica que los elementos definidos en este Esquema concreto ( Atlas, Pais, Nombre, Capital, Población, Extensión ) pertenecen al espacio de nombres indicado, que llamaremos de destino (target), y que obviamente se pasa al documento instancia para su uso correspondiente. xmlns= : indica el aspecto de nombres por defecto del Esquema, que será : de forma que cuando aparece una referencia como ref= Pais sin ningún prefijo, se sabe que se refiere a la declaración del elemento Pais en este espacio de nombres. Por su parte, en lo que se refiere al documento instancia miatlas.xml se observa, que además del espacio de nombres indicado por targetnamespace, aparece la declaración xmlns:xsi= instance que se encarga de pasar del espacio de nombres del Esquema al espacio de nombres de la instancia, o dicho en otras palabras, relaciona el documento instancia con su correspondiente Esquema. Por tanto existen espacios de nombres con distintos cometidos : a)el que define los Esquemas ( xmlns:xsd= b)el ( los ) de destino ( targetnamespace ) específicos del esquema construido al que se refieren los correspondientes documentos instancia. c)el por defecto que puede ser o no uno de los dos anteriores. d)el que permite usar el Esquema en el documento instancia. Puesto que un Esquema opcionalmente puede especificar un espacio de nombres por defecto, éste está implícito en cualquier referencia a un componente global que no Juan Manuel Alcázar Donaire 9/28

10 incluya ningún prefijo. Así, si el espacio de nombres por defecto correspondiente a la URI asociada al prefijoxsd, al usar el nombre token implica automáticamente referirse al nombre cualificado xsd:token. Nótese que el espacio de nombres por defecto se aplica sólo a referencias en un Esquema, y por tanto estos espacios por defecto no tienen impacto en sus documentos instancia. Como se ha visto en los ejemplos vistos, es habitual usar el espacio de nombres indicado por targetnamespace como espacio de nombres por defecto de la forma: <?xml version= 1.0 encoding= UTF 8?> <xs:schema xmlns:xs= targetnamespace= xmlns= <xs:schema> lo que es una buena práctica pues todas las declaraciones del Esquema serán parte del propio espacio de nombres y no aparecerán errores por conflictos de espacios de nombres o por tratar de referenciar componentes que no estén definidos. Además, hay que hacer notar que el nodo raíz schema especifica los atributos elementformdefault y attributeformdefault, ( que especifican cómo deben aparecer los elementos en el documento instancia final ) que pueden ser unqualified o qualified. Con esta opción se declara si los elementos del Esquema se importan o no de otro espacio de nombres. En el primer caso se indica que en los documentos instancia del Esquema se pueden usar nombre sin cualificar, mientras que en el caso qualified, todo elemento utilizado en el documento instancia debe pertenecer a un espacio de nombres, aunque ello se haga a través del espacio de nombres por defecto, como ocurre en el ejemplo. A pesar de su aparente trivialidad, una de las tareas más importantes al construir un esquema XML consiste en determinar los espacios de nombres involucrados, ya que al poder existir varios en un mismo Esquema, la forma como éstos se declaren determina la capacidad para importar e incluir nuevos Esquemas ( o sus elementos ) en un documento, ya que el proceso de actualización frecuentemente supone tener que incluir nuevos espacios de nombres. Por otro lado, debe tenerse en cuenta que la variedad de prefijos dificultan la comprensión de los documentos instancia, con confusiones acerca del espacio de nombres que se aplica en cada momento, caso que hay que saber controlar en la práctica. 4.8 Espacios de nombres y documentos instancia Juan Manuel Alcázar Donaire 10/28

11 Cuando un determinado documento instancia se asocia con uno o más Esquemas durante el correspondiente proceso de validación, es necesario identificar tanto las declaraciones ( de elemento y atributo ) como las definiciones ( de tipos de datos ) que van a usarse al objeto de poder contrastarlos con el Esquema que les corresponda. El espacio de nombres de destino juega un papel importante en este proceso de identificación, ya que al definir un Esquema se dispone de un nuevo vocabulario para uso de sus documentos instancia y en consecuencia los elementos y atributos respectivos se identifican por este espacio de destino. Repasemos el encabezado del documento instancia del ejemplo que estamos manejando y que adopta la forma : <?xml version= 1.0?> <Atlas xmlns= xmlns:xsi= instance xsi:schemalocation= > donde al declarar sin prefijo, el resultado por defecto es indicar al validador de Esquemas donde pertenecen los elementos usados en esta instancia. A continuación se dice que se usa el espacio de nombres: instance y finalmente xhemalocation indica que el espacio de nombres está definido en atlas.xsd. Se observa que con esta combinación de espacios de nombres, el documento instancia no presenta ningún problema de especificación y conviene retener este tipo de encabezamiento a la hora de trabajar con documentos instancia. 4.9 Estructuras de datos en Esquemas En XML conviven dos perspectivas distintas respecto a las estructuras de datos; por un lado, la creación de documentos como ejemplo de datos semiestructurados, buscando un formato compatible con la idea tradicional de documento, con grandes bloques de texto, tales como un libro o una carta, cuya estructura ya es conocida y aceptada por todos, y por otro, más específico, la definición de datos cuya estructura no está estandarizada y donde cada autor de un documento debe tomar sus decisiones. Esta última perspectiva es parecida a la que se da a la hora de definir los esquemas de una base de datos, donde los documentos contienen piezas de información que se estructuran de la forma que sea más conveniente para cada aplicación. Juan Manuel Alcázar Donaire 11/28

12 Desde la segunda visión, en Informática los tipos de datos sirven para dar un marco en el que se comparta significado, al tiempo que se refuerza su integridad. Así, no es adecuado declarar Fecha como un simple tipo cadena, ya que con ello cualquier conjunto de caracteres, incluido los que no tengan nada que ver con una fecha, sería aceptado como tal. Es obvia la necesidad de restringir los valores permitidos y así se hace con Fecha : un tipo de dato predefinido y que representa un día específico de la forma : CCAA MM DD, con rango para CC:00 99, para AA : 00 99, para MM : y para DD : si el mes es el 2; si el mes es el 2 y Gyear ( año del calendario Gregoriano ) es bisiesto; si el mes es el 4, 6, 9, o el 11 y si el mes es el 1, 3, 5, y, 8, 10 o 12. Se notará que usando sólo DTD no se tiene predefinido este tipo de dato, por lo que los Esquemas han tenido que solucionar esta carencia proporcionando un mecanismo para que se pueda escribir Fecha adecuadamente. Puesto que en XML los valores de elementos y atributos deben tener un significado léxico, los Esquemas especifican tipos de datos, y no se quedan en asumir las estructuras de datos básicas utilizadas en la mayor parte de los lenguajes de programación. A este proceso de obtención de nuevos tipos de datos a partir de otros ya existentes se llama derivación. Considérese el ISBN de un libro consistente de nueve dígitos seguidos por otro o por el carácter X, que debe ser una cadena restringida a : d ddddd ddd d, d ddd ddddd d, d dd ddddd d. Para controlar los patrones (pattern) válidos se recurre a la sintaxis de las expresiones regulares propias de las gramáticas formales, con lo que se puede especificar las restricciones para las tres cadenas permitidas de la forma : <xsd:simpletype name= tipoisbn > <xsd:restriction base= xsd:string > <xsd:pattern value= \d{1} \d{5} \d{3} \d{1} \> <xsd:pattern value= \d{1} \d{3} \d{5} \d{1} \> <xsd:pattern value= \d{1} \d{2} \d{6} \d{1} \> <xsd:restriction> </xsd:simpletype> De forma más concreta, en Esquemas XML se llama tipo de datos a una tripleta ordenada cuyos valores pertenecen respectivamente a : Un espacio de valores ( cadenas en este ejemplo ) para los valores del tipo de datos especificado. Un espacio léxico ( la secuencia de literales del ISBN ). Las facetas que caracterizan las propiedades de cada espacio de valores ( los patrones descritos ). En Esquemas XML existen hasta 15 facetas, algunas de las cuales son : length, minlength, maxlength, pattern, enumeration, mininclusive, maxinclusive, minexclusive y maxexclusive. Juan Manuel Alcázar Donaire 12/28

13 A los elementos que contienen subelementos y/o incorporan atributos se les llama de tipo complejo, mientras que si sólo contienen números, cadenas, fechas, etc... se dice que son de tipo simple e forma que los tipos complejos se derivan a partir de tipos simples. Los elementos simpletype y complextype de Esquemas XML definen cualquier nuevo tipo de dato bien sea simple o complejo. En cuanto a los atributos, obviamente sólo tienen datos de tipo simple Tipos Simples Un tipo de dato simple puede ser predefinido ( incorporado al Espacio de Nombres de los Esquemas ) o derivado ( definido por el autor del Esquema ). Entre los predefinidos se distingue. tipos de datos simples primitivos Datos simples primitivos Ejemplos y formato String Hola Mundo Bolean {true,false,1.0} Decimal 7.08 Flotante 12.56E3, 12, 12560, 0, 0, INF, INF, NUM Double 12.56E3, 12, 12560, 0, 0, INF, INF, NUM Duration P1Y2M3DT10H30M12.3S DateTime CCYY MM DDThh:mm:ss Time hh:mm:ss.sss Date CCYY MM DD GyearMonth CCYY MM Gyear CCYY GmonthDay MM DD Gday DD ( date cuenta de los 3 rayas ) HexBinary una cadena hexadecimal Base64Binary una cadena en base 64 AnyURI AnyType Tipo base para todos los esquemas Úname Un nombre de espacio y nombres cualificado NOTATION Una NOTATION según la especificación XML Ejemplos de declaración de elementos usando tipos primitivos son : Juan Manuel Alcázar Donaire 13/28

14 <xs:element name= temperatura type= xs:decimal /> donde el elemento temperatura tiene un valor decimal; por ejemplo : <temperatura>98.6</temperatura> <xs:element name= fiesta type= xs:date /> donde el elemento fiesta tiene un valor CCYY MM DD; por ejemplo : <fiesta> </fiesta> Predefinidos derivados NormalizedString Token Language Subtipo del tipo de dato primitivo Una cadena sin tabuladores, sangrías, o retornos de carro. Cadena sin/con tabulaciones, espacios consecutivos,etc. Cualquier valor xml: lang válido, por ejemplo : EN, FR,... IDREFS debe usarse sólo con atributos ENTITIES debe usarse sólo con atributos NMTOKEN debe usarse sólo con atributos NMTOKENS debe usarse sólo con atributos Name NCName part ( ningún espacio de nombres calificador ) ID debe usarse sólo con atributos IDREF debe usarse sólo con atributos ENTITY debe usarse sólo con atributos Integer 456 NomPositiveInteger desde negativo infinito a cero NagativeInteger desde negativo infinito a 1. Long a Int a Short a Byte 127 a 128 NonNegativeInteger De cero a infinito UnsignedLong 0 a UnsignedInt 0 a UnsignedShort 0 a UnsignedByte 0 a 255 PositiveInteger 1 a infinito Como ejemplo de uso de datos predefinidos, podemos citar su uso para manejar sucesiones de ceros y unos; por ejemplo : Juan Manuel Alcázar Donaire 14/28

15 <xsd:element name= cero type= xsd:unsignedbyte fixed= 0 /> o el uso de enteros positivos, por ejemplo : <element name= codigopostal type= positiveinteger /> Es el momento de recalcar que un tipo de dato en Esquemas se dice que es atómico si es indivisible como tal dato. Por ejemplo, dato el valor de ES para España definido como NMTOKEN ( tipo de dato predefinido derivado ) en un elemento Estado ninguna parte del mismo, como sería el carácter S, tiene ningún significado por sí mismo Definición y Derivación de datos simples A partir de los datos simples existe la posibilidad de obtener nuevos tipos de datos simples, bien por definición ( listas y unión ) o por derivación ( por restricción a partir de un tipo base utilizando las facetas correspondiente). Para definir y derivar nuevos datos simples se usa el elemento simpletype que constituye la representación de un tipo simple en un documento, identificándolo con un nombre. Los contenidos posibles de este elemento son los elementos : List, Union, y Restriction. Adelantemos que aunque los tipos simples de deriven por restricción, en el caso de los complejos también se hace por extensión. El elemento list : en Esquemas, se entiende por lista a una secesión de elementos simples delimitados por espacios en blanco. Por ejemplo : <!ElementoLista> valor1 valor2 valor3</elementolista> Los elementos de una lista pueden ser globales o locales, siempre que todos los valores contenidos en ella sean de un mismo tipo ( identificado por medio del atributo itemtype). Supóngase que se tiene un tipo simple llamado mientero, derivado de los enteros con un rango de a 99999, y a partir de él se crea la lista : <xsd:simpletype name= listamitipoentero > <xsd:list itemtype= mientero /> <xsd:simpletype> con ello un valor válido para listamitipoentero puede ser : <listamitipoentero> </listaMiTipoEntero> Juan Manuel Alcázar Donaire 15/28

16 El elemento union: así como las listas exigen que el valor de sus miembros sean de un mismo tipo, el tipo union crea un nuevo tipo simple predeterminado que el valor de un elemento o atributo contenga una o más instancias con tipos construidos con la unión de múltiples tipos atómicos o listas. El principal atributo del elemento union o membertypes que proporciona la relación de sus posibles tipos simples globales, esto es, su valor consiste en una lista de listas con todos los tipos de datos que constituyen cada unión concreta, siendo las dos facetas que se aplican : pattern y enumeration. Supongase que se quiere crear un tipo para representar países, bien por dos letas bien por un código numérico de cinco cifras. Para ello se usa el tipo UnionCodigos construido por un tipo atómico (NMTOKEN, donde recurriremos a un Estado como ES) y un tipo lista ( listamitipoentero, una lista de cinco cifras), que se especifica mediante: <xsd:simpletype name= UnionCodigos > <xsd:union membertypes= Estado listamitipoentero /> </xsd:simpletype> Asumiendo que se ha declarado un elemento llamado codigospostales del tipo UnionCodigos, son instancias válidas para este elemento los siguientes ejemplos : <codigospostales>es</codigospostales> <codigospostales> </codigospostales> El elemento restriction proporciona la funcionalidad de especificar las facetas que restringen un tipo simple ya definido, que se llama tipo base. Con el uso conjunto de restriction ( para indicar el tipo base e identificar que restringen su rango de valores ) y de simpletype ( para definir y dar nombre al nuevo tipo ) se derivan nuevos tipos simples. Este elemento especifica los valores permitidos de las facetas del tipo base, por medio de la sintaxis : <xsd:simpletype name= nombre > <xsd:restriction base= xsd:string > <xsd:facet value= valor /> <xsd:facet value= valor /> <xsd:restriction> </xsd:simpletype> El atributo básico de restriction obviamente es base que identifica el tipo simple sobre el que se trabaja. Así por ejemplo, sabiendo que el tipo de datos cadena tiene seis facetas opcionales ( length, minlength, maxlength, pattern, enumeration, whitespace ) se deriva un nuevo tipo llamado NumeroTelefono de la forma : <xsd:simpletype name= NumeroTelefono > Juan Manuel Alcázar Donaire 16/28

17 <xsd:restriction base= xsd:string > <xsd:length value= 8 /> <xsd:pattern value= \d{3} \d{4} /> <xsd:restriction> </xsd:simpletype> donde se determina que se trabaja con una cadena de ocho caracteres, que debe seguir el patrón ddd ddd, aunque en este ejemplo concreto, al usarse una expresión regular es redundante el uno de la fecha de longitud de la cadena. En el proceso de restricción, el uso de la faceta enumeration es particularmente útil ya que limita el conjunto de valores distintos que pueden aparecer como valores de cualquier tipo simple, con la obvia excepción del tipo bolean. Por ejemplo, se puede utilizar la faceta enumeration para definir un nuevo tipo simple llamado USAEstado, derivado de string, cuyos valores deben ser unas de las abreviaciones para los estados de USA : <xsd:simpletype name= USAEstado > <xsd:restriction base= xsd:string > <xsd:enumeration value= AK /> <xsd:enumeration value= AL /> <xsd:enumeration value= AR />... <xsd:restriction> <xsd:simpletype> 4.12 Elementos y atributos en Esquemas Puesto que los tipos complejos pueden integrar distintos elementos, conviene antes de entrar en más detalles acerca de estos tipos, ver previamente los elementos element y attribute. Adelantemos que ambos pueden tener valores por defecto que se declaran por medio del atributo default, aunque el efecto de este atributo presenta matices en cada caso y que además, el atributo fixed se usa tanto en las declaraciones de elemento como de atributo para asignar unos valores predeterminados. Nótese que el concepto de valor fixed y default en un atributo son mutuamente excluyentes, y es un error que una declaración los contenga a ambos. Juan Manuel Alcázar Donaire 17/28

18 El elemento element Como se ha adelantado, los elementos que van a aparecer en un documento instancia deben aparecer en el Esquema con un elemento element, cuyos atributos más significativos son : maxoccurs y minoccurs : determinan el número máximo ( mínimo ) de veces que el elemento puede aparecer en un documento instancia; obviamente, sólo se aplican a atributos de elementos de tipo real. name : especifica el nombre usado para referenciar un tipo de elemento tanto en el resto del Esquema como en un documento instancia. ref : hace referencia a un elemento global ya declarado. Es mutuamente excluyente con name. type : especifica el tipo de dato del elemento, con un valor nombre referido a un tipo global, simple o complejo. Un ejemplo de este elemento es : <xsd:element name= algunelemento type= xs:string /> La mayoría de elementos que se usan tienen elementos locales ( tanto simpletype como complextype ) o una referencia a un tipo global ( simple o complejo ) a través del atributo type siendo las opciones de contenido para el elemento element : annotation, simpletype y complextype El elemento attribute En un Esquema XML los atributos se declaran por medio del elemento attribute que a su vez tiene una serie de atributos que ponen restricciones a las propiedades de esta declaración, cuya panorámica depende de su ubicación dentro del Esquema ( como se sabe un atributo global debe declararse como hijo del elemento schema ). Dado el fragmento : <xsd:schema> <xsd:attribute name= miatributo /> <xsd:element name= algunelemento type= xs:string /> </xsd:schema> Juan Manuel Alcázar Donaire 18/28

19 el atributo miatributo es global, y puede referenciarse en cualquier elemento o grupo de atributos del documento. En el caso que se quiera declarar un atributo de forma local, éste se coloca como hijo de la declaración del elemento correspondiente; por ejemplo : <xsd:schema> <xsd:element name= algunelemento > <xsd:complextype> <xsd:attribute name= miatributo /> </xsd:complextype> </xsd:element> </xsd:schema> Los atributos de un elemento son muy parecidos a los vistos para element; la diferencia más importante es que los atributos son siempre de tipo simple. Un atributo específico del elemento attribute es use, que da la posibilidad de limitar el uso del atributo en un documento instancia, pudiendo tomar los valores : optional, prohibited, y required, cuyos significados respectivos son evidentes. Señalar que en los atributos como norma se aplica el valor por defecto cuando los atributos no quedan determinados Tipos Complejos Los posibles modelos de contenido que se pueden dar en un tipo complejo, además del caso obvio de contener sólo datos son : Contenido de elementos : cuando un elemento solo contiene otros elementos, que reciben el nombre de grupo. Contenido mixto : cuando un elemento tiene como valor tanto datos como elementos hijos, siendo muy frecuente que un esquema tenga elementos con subelementos que contengan texto. Para especificar la presencia de este contenido se usa el atributo mixed ( con valores cierto o falso ). Contenido vacío : un elemento se dice es vació si sólo contiene atributos, por lo que para su representación se usa un tipo complejo de tal manera que en su contenido sólo permita elementos sin que se declare ninguno de ellos, con lo que se obtiene este contenido vacío ( recalcar que el valor por defecto sólo se aplica cuando los elementos son vacíos ). Para su representación se define un tipo anónimo basado en la restricción del tipo predefinido anytype sin que exista ningún contenido en el elemento. Juan Manuel Alcázar Donaire 19/28

20 4.16 Grupos de elementos Se llama grupo a los elementos que puede contener un tipo complejo, pudiendo tener un nombre determinado ( representado por el elemento group ) o carecer de él. El básico definir en el Esquema, el modo en que estos grupos deben aparecer en el documento instancia, cosa que puede ser: en un determinado orden o secuencia ( sequence ), pudiendo el autor del documento instancia elegir alguno de los elementos del grupo ( choice ), o que se dé al autor total libertad, tanto respecto al orden como a la selección del elemento ( all ). El elemento sequence. Proporciona una representación de un conjunto ordenado de elementos, de forma que en el documento instancia correspondiente, los elementos tengan el mismo orden de aparición que en el Esquema; nótese que puede haber cero o muchos elementos para cada tipo, dependiendo de los valores minoccurs y maxoccurs de cada elemento. Este elemento sequence ya ha sido utilizado en los ejemplos vistos previamente. El elemento choice. Proporciona un mecanismo para describir una selección dentro de un grupo, de forma que el documento instancia contiene el elemento del grupo especificado por el elemento choice en el Esquema. Los atributos maxoccurs y minoccurs permiten que el documento instancia seleccione el número de elementos ( por ejemplo, entre dos y cuatro ). Veamos cómo expresar distintas alternativas : 1) Una selección entre varias : <xsd:element name= transporte > <xsd:complextype> <xsd:choice> <xsd:element name= tren type= xsd:string /> <xsd:element name= avion type= xsd:string /> <xsd:element name= automovil type= xsd:string /> </xsd:choice> </xsd:complextype> </xsd:element> De forma que al ser choice equivalente a un o exclusivo, el elemento transporte sólo puede contener uno de los tres elementos tren, avión o automóvil. 2) Dar la posibilidad de repetir la opción. Un ejemplo es una cadena de bits: <xsd:element name= cadena binaria > <xsd:complextype> Juan Manuel Alcázar Donaire 20/28

21 <xsd:choice minoccurs= 0 maxoccurs= unbounded > <xsd:element name= cero type= xsd:unsignedbyte fixed= 0 /> <xsd:element name= uno type= xsd:unsignedbyte fixed= 1 /> </xsd:choice> </xsd:complextype> </xsd:element> El elemento all. Especifica un conjunto sin ordenar de un grupo de elementos, de forma que cada uno de ellos puede estar presente en un documento instancia sin ninguna restricción respecto al orden. En el ejemplo de Atlas, al escribir : <xsd:element name= Pais maxoccurs= unbounded > <xsd:complextype> <xsd:all> <xsd:element name= Nombre type= xsd:string /> <xsd:element name= Capital type= xsd:string /> <xsd:element name= Poblacion type= xsd:int /> <xsd:element name= Extension type= xsd:int /> <xsd:all> <xsd:complextype> <xsd:element> se permite que los elementos hijo del elemento Pais puedan dares en cualquier orden en los documentos instancia Tipos complejos : Extensión y Derivación. Recordando que todo tipo complejo es un tipo derivado, se nos presentan tres posibles procesos a abordar : La extensión de un tipo complejo, cosa no posible en los tipos simples. La conversión de un tipo simple a uno complejo que incorpore atributos que no puede tener un tipo simple. La conversión de un tipo complejo en un nuevo tipo complejo. Obviamente para todas estas operaciones es necesario enmarcarlas en el uso del elemento complestype y vamos a ver a continuación los elementos adicionales que permiten llevar a cabo estos procesos propios de los tipos complejos. Juan Manuel Alcázar Donaire 21/28

22 Elemento any. Se utiliza normalmente para extender en el documento instancia un elemento existente. En particular el elemento any permite al autor del documento instancia trabajar con elementos no especificados en el Esquema. Así, por ejemplo añadiendo el elemento Pais : <xsd:any minoccurs= 0 /> se indica que al construir un documento instancia, opcionalmente, se puede extender el contenido del mismo con cualquier elemento que sea necesario. El mecanismo xsd:any, llamado en la jerga de los Esquemas wild card ( un término utilizado en tenis para referirse a la posibilidad que tiene el organizador de un torneo para dar acceso a él a alguien que no cumpla las condiciones generales ), controla el posible uso de elementos pertenecientes a otros espacios de nombres, que especifica este elemento, por medio de sus valores. El uso de xsd:any permite extender los espacios de nombres del Esquema de una forma controlada. Por tanto xsd:any con su atributo namespace controla los elementos que se pueden admitir procedentes de las extensiones de un cierto espacio de nombres, los valores más frecuentes de este atributo son : ##any ( se puede extender el Esquema usando un elemento de cualquier espacio de nombres ) y ##targetnamespace ( sólo se permiten extender con los elementos del target namespace que aparece en el Esquema ). Elemento anyattribute. Permite extender en el documento instancia aquellos atributos no especificados por el Esquema. Puesto que un atributo es un tipo simple para esta extensión, hay que seguir la sintaxis que se indica en los párrafos siguientes y que tiene como objetivo que un elemento simple pueda extenderse a uno complejo, al objeto de poder contener atributos. Elemento simple content. Como se ha dicho, sólo los modelos de contenido de tipo complejo pueden tener atributos y para que ello ocurra, inevitablemente hay que recurrir al elemento complextype si se quiere especificar un atributo a un tipo simple. Para incorporar estos atributos vamos a presentar una forma para su extensión directa mediante el elemento simplecontent y la correspondiente conversión a tipo complejo, cuyo resultado es un contenido sin ningún elemento hijo, pero sí con atributos. Supongamos que se quiere incorporar a un Esquema un elemento que se puede escribir de la forma : <elevacion unidades= metros >1440</elevacion> donde se tiene un contenido simple, concretamente un entero y un atributo unidades veamos su declaración por medio del fragmento : Juan Manuel Alcázar Donaire 22/28

23 <xsd:element name= elevacion > <xsd:complextype>1 <xsd:simplecontent>2 <xsd:extensión base= xsd:integer >3 <xsd:attribute name= unidades type= xsd:string use= requiered />4 </xsd:extension> <xsd:simplecontent> <xsd:simplextype> <xsd:element> 1. El elemento elevación contiene un atributo, por lo que es necesario el uso de <xsd:complextype>. 2. El elemento elevación no contiene elementos hijos, por lo que tiene a pesar de tener atributos, un contenido simple y se escribe : <xsd:simplecontent> 3. Se extiende el contenido simple ( un entero ) con un atributo, utilizado : xsd:extensión base= de forma análoga a como lo utilizamos en la restricción con : xsd:restriction base= en el caso de tipos simples ( y que obviamente también puede usarse para el caso de un tipo complejo ). 4. Se especifica el atributo que se incluye, al cual se le puede dar el tipo de dato adicional que se desee. Elemento complexcontent. Permite especificar las restricciones y extensiones que se deseen a partir de un tipo complejo. Este elemento proporciona más flexibilidad que simplecontent, con un parecido. A partir del ejemplo de los códigos postales, vamos a definir un tipo complejo que se adapte a la dirección postal para Estados Unidos, asumiendo que ya tenemos definido el tipo Direccion que nos servirá de base : <complextype name= USADireccion > <complexcontent> <extensión base= tipo:direccion > <sequence> <element name= estado type= USAEstado /> <element name= codigopostal type= positiveinteger /> </sequence> </extension> </complexcontent> </complextype> Juan Manuel Alcázar Donaire 23/28

24 4.8 Completar el documento Esquema Para completer en un Esquema los componentes propios de un documento XML, falta comentar la forma como éste se refiere a los comentarios y a las IPs de los documentos instancia que define. Generalización de los comentarios : La información adicional que normalmente se incluye en un comentario debe generalizarse necesariamente en los Esquemas, pues éstos proporcionan información tanto a las personas, como a los métodos de procesamiento automático que se ejecutan en el momento de crear los documentos instancia. Los elementos que hacen posible esta documentación son : Elemento annotation. Proporciona un mecanismo para documentar o anotar los componentes de un Esquema, haciendo una función similar a los comentarios, aunque dando una información más completa, ya que annotation no se reduce a la forma: <! texto >, sino que puede proporcionar documentación tanto para quien maneje el documento como para el procesado automático del mismo. Elemento documentation. Consiste bien en un texto, legible por un humano, bien en una referencia a un texto dado por un URI, siempre dentro de un elemento annotation. Su contenido en un documento instancia no tiene límites, de forma que un elemento annotation puede contener muchos elementos documentation y cada uno puede presentar información más o menos redundante, como sería el caso del uso de lenguajes distintos. Sus dos atributos opcionales son source ( una URI que el procesador no valida, que representa cualquier documento considerado relevante ) y xml:lang ( que especifica el lenguaje de la documentación ). Elemento appinfo. Proporciona información a otras aplicaciones, lo que supone un procesamiento externo al propio documento y que sólo un elemento annotation puede contener Llamadas a procedimientos externos: el elemento notation En Esquemas XML existe un mecanismo para que el procesador localice programas externos o Instrucciones de Proceso, aunque no las valide durante el proceso de análisis del documento instancia. Para llevar a cabo esta misión, igual que su homólogo en los DTDs, se usa el elemento notation, que proporciona un mecanismo para que el procesador pueda localizar tanto programas externos o IP sin que se validen en el momento de analizar el documento instancia correspondiente. Juan Manuel Alcázar Donaire 24/28

25 Evidentemente, debe existir un elemento notation para cada referencia externa de acuerdo con una notación predefinida, de forma que los atributos para cada elemento notation deben especificar un nombre y un recorrido para poder obtener las correspondientes instrucciones de procesamiento o programas externos. La única opción de contenido que incorpora el elemento notation coincide con el ya visto, elemento annotation que proporciona la información necesaria sobre el recurso que se invoca, cada vez que se use el elemento notation Construcción de Esquemas con Documentos múltiples A medida que un Esquema se amplía, por cualquier motivo ( habitualmente relacionado con el mantenimiento, la extensibilidad, la accesibilidad y la legibilidad ) es aconsejable dividir su contenido entre varios documentos, y por ello debe contarse con mecanismos que permitan las composiciones y creaciones de Esquemas a partir de distintos documentos, diversos entre sí. Para poder proceder a esta integración hay que distinguir según si el espacio de nombres de destino sobre el que actúan estos documentos sea el mismo o que no lo sea, siendo más simple obviamente el primer caso. Supongamos que a la hora de construir un Esquema multas.xsd, se contara con un Esquema previo ( vias.xsd ) que resolvera todas las cuestiones realcionadas con las definiciones de las carreteras internacionales, tal como : <schema targetnamespace= xmlns= xmlns:via= > <complextype name= Carretera > </complextype> <complextype name= EspanaCarretera >... </complextype> <complextype name= PortugalCarretera >... </complextype> <complextype name= UKCarretera >... </complextype>... </schema> Juan Manuel Alcázar Donaire 25/28

26 Resulta evidente que su incorporación al Esquema encargado de manejar las multas daría lugar a un Esquema multas.xsd más potente para manejo de multas internacionales. Elemento incluye. Añade componentes desde otros Esquemas distintos al espacio de nombres propio del Esquema, siempre que el espacio de nombres de destino de los elementos incluidos y el del Esquema que los incluye sea el mismo. Podemos escribir : <schema targetnamespace= xmlns= xmlns:via= > <annotation>..... </annotation> <! Incluye la definicion de la carretera > <include schemalocation= /> <element name= multacomprobante type= via:multacomprobantetype /> <element name= comentario type= string /> <element name= conductor type= string /> <complextype name= MultaComprobanteType > <! se incluye información de la carretera donde se ha efectuado la infracción con el uso de VIA > </schema> donde como se observa para integrar vias.xsd en multas.xsd se ha recurrido a : <incluye schemalocation= /> Se observa que el efecto de incluye, consiste en incorporar las definiciones y declaraciones contenidas en vias.xsd para hacerlas accesibles al espacio de nombres del Esquema multas.xsd, siempre con el uso del espacio de nombre común : Un elemento incluye especifica la localización de un documento XML, y tiene como opción de contenido el ubicuo elemento annotation. Los atributos que puede tener son : Id para identificar un elemento del Esquema. SchemaLocation para especificar los componentes a incluir. El valor de este atributo schemalocation es una URI que especifica : La localización de un documento Esquema. Juan Manuel Alcázar Donaire 26/28