esquema xml parte 0_ fundamentos

Nota de Traducción

Traducción al español: Jose Manuel Alonso.

Este documento es una traducción al español de la recomendación del W3C�ypuede encontrarse en http://www.w3c.es/Traducciones/es/TR/2001/REC-xmlschema-0-20010502/.�El documento original del W3C es la única referencia oficial válida. Estedocumento fue finalizado el 2 de Junio de 2001. La última revisión de esta traducciónse realizó el 15 de Julio de 2002.

Este documento puede contener errores de traducción, los cuales deben sercomunicados a Jose Manuel Alonso. En ocasiones aparecen aclaraciones entrecorchetes y con el color de fondo de esta nota de traducción, por ejemplo,[aclaración], al lado de el vocablo o expresión original del Inglés en su primeraaparición. También se han omitido de forma voluntaria algunas tildes especialmente enla traducción de elementos del código con el fin de aumentar la legibilidad.

Agradezco a César Acebal el apoyo dado durante el proceso de traducción y engeneral también al grupo de XJumbo por los buenos momentos.

Lo que sigue es la traducción del documento original.

Esquema XML Parte 0: Fundamentos

Recomendación del W3C, 2 de Mayo de 2001

Esta versión:http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/

Última versión:http://www.w3.org/TR/xmlschema-0/

Versión anterior:http://www.w3.org/TR/2001/PR-xmlschema-0-20010330/

Editor:David C. Fallside (IBM) [email protected]

Copyright ©2001 W3C® (MIT, INRIA, Keio), Todos los Derechos Reservados. Son aplicableslas reglas del W3C sobre� obligaciones, marcas registradas, uso de documentos ylicencias de software.�

�

Resumen

Esquema XML Parte 0: Fundamentos es un documento no-normativo hecho paraproporcionar una descripción fácilmente legible de las posibilidades del Esquema XML, yestá orientado a un entendimiento rápido sobre cómo crear esquemas utilizando el

Esquema XML Parte 0: Fundamentos http://www.w3c.es/Traducciones/es/TR/2001/REC-xmlschema-0-200...

1 de 57 16/01/2014 21:41

lenguaje Esquema XML. Esquema XML Parte 1: Estructuras y Esquema XML Parte 2:Tipos de Datos proporcionan la descripción normativa completa del lenguaje EsquemaXML. Estos fundamentos describen las características del lenguaje a través de numerososejemplos que son complementados con referencias extensivas a los textos normativos.

Estado de este Documento

Esta sección describe el estado de este documento en el momento de su publicación. Otrosdocumentos pueden reemplazar a este documento. El último estado de esta serie dedocumentos se mantiene en el W3C.

Este documento ha sido revisado por miembros del W3C y otras partes interesadas y hasido ratificada por el Director como una Recomendación del W3C. Es un documentoestable y puede ser utilizado como material de referencia o citado como referencianormativa desde otro documento. El papel del W3C al hacer la Recomendación es el deatraer la atención sobre la especificación y promover su amplia difusión. Esto mejora lafuncionalidad e interoperabilidad de la Web.

Este documento ha sido producido por el Grupo de Trabajo del W3C sobre el EsquemaXML como parte de la Actividad XML del W3C. Las metas del lenguaje Esquema XML sondiscutidas en el documento de Requisitos del Esquema XML. Los autores de estedocumento son miembros del Grupo de Trabajo del W3C sobre el Esquema XML. Haypartes de este documento editadas por diferentes personas.

Esta versión del documento incorpora algunos cambios editoriales de versiones anteriores.

Por favor, comunique errores en este documento a [email protected](archivo). La lista de errores conocidos en esta especificación está disponible enhttp://www.w3.org/2001/05/xmlschema-errata.

La versión Inglesa de esta especificación es la única versión normativa. La informaciónsobre traducciones de este documento está disponible en http://www.w3.org/2001/05/xmlschema-translations.

Una lista actualizada de Recomendaciones del W3C y otros documentos técnicos puedeencontrarse en http://www.w3.org/TR.

Tabla de Contenidos

1 Introducción2 Conceptos Básicos: Hoja de Pedido�2.1 El Esquema de la Hoja de Pedido�2.2 Definición de Tipos Complejos, Declaración de Elementos y Atributos��2.2.1 Restricciones de Ocurrencia��2.2.2 Elementos y Atributos Globales��2.2.3 Conflictos de Nombres�2.3 Tipos Simples��2.3.1 Tipos Lista��2.3.2 Tipos Unión�2.4 Definiciones de Tipos Anónimos�2.5 Contenido de Elementos��2.5.1 Tipos Complejos desde Tipos Simples��2.5.2 Contenido Mixto��2.5.3 Contenido Vacío��2.5.4 Tipo Any [Tipo Cualquiera]


2 de 57 16/01/2014 21:41

�2.6 Anotaciones�2.7 Construcción de Modelos de Contenido�2.8 Grupos de Atributos�2.9 Valores Nulos3 Conceptos Avanzados I: Espacios de Nombres, Esquemas y Calificación�3.1 Espacios de Nombres y Locales Sin Calificar�3.2 Locales Calificados�3.3 Declaraciones Locales contra Globales�3.4 Espacios de Nombres Sin Declarar4 Conceptos Avanzados II: Hoja de Pedido Internacional�4.1 Un Esquema en Múltiples Documentos�4.2 Derivación de Tipos por Extensión�4.3 Uso de Tipos Derivados en Documentos Instancia�4.4 Derivación de Tipos Complejos por Restricción�4.5 Redefinición de Tipos y Grupos�4.6 Grupos de Sustitución�4.7 Elementos y Tipos Abstractos�4.8 Control de la Creación y Uso de Tipos Derivados5 Conceptos Avanzados III: El Informe Trimestral�5.1 Especificar Unicidad�5.2 Definición de Claves y sus Referencias�5.3 Restricciones del Esquema XML frente a Atributos ID de XML 1.0�5.4 Importación de Tipos��5.4.1 Bibliotecas de Tipos�5.5 Elemento Any [Elemento Cualquiera], Atributo Any [Atributo Cualquiera]�5.6 schemaLocation [ubicación del Esquema]�5.7 Concordancia

Apéndices

A ReconocimientosB Tipos Simples y sus PropiedadesC Uso de Entities [Uso de Entidades]D Expresiones RegularesE Índice

1 Introducción

Este documento, Esquema XML Parte 0: Fundamentos, proporciona una descripción entérminos sencillos a la definición del lenguaje Esquema XML, y debe ser utilizado junto conlas descripciones formales del lenguaje contenidas en las Partes 1 y 2 de la especificacióndel Esquema XML. El público al que se dirige este documento incluye desarrolladores deaplicaciones cuyos programas leen y escriben esquemas, y autores de esquemas quenecesitan conocer las características del lenguaje, especialmente las que proporcionanfuncionalidad superior a la que posibilitan los DTDs. El texto asume que tienes unentendimiento básico de XML 1.0 y XML-Namespaces [Espacios de Nombres XML]. Cadauna de las secciones principales de estos fundamentos introduce nuevas característicasdel lenguaje, y describe esas características en el contexto de ejemplos concretos.

La Sección 2 cubre los mecanismos básicos del Esquema XML. Describe cómo declarar


3 de 57 16/01/2014 21:41

los elementos y atributos que aparecen en los documentos XML, la distinción entre tipossimples y complejos, la definición de tipos complejos, el uso de tipos simples para valoresde elementos y atributos, las anotaciones del esquema, un mecanismo simple parareutilizar definiciones de elementos y atributos, y los valores nulos.

La Sección 3, la primera sección avanzada de los fundamentos, explica las bases sobrecómo son utilizados los espacios de nombres en XML y en los esquemas. Esta sección esimportante para entender muchos de los temas que aparecen en las otras seccionesavanzadas.

La Sección 4, la segunda sección avanzada de los fundamentos, describe mecanismospara derivar tipos de tipos existentes, y para controlar esas derivaciones. Esta seccióntambién describe mecanismos para mezclar fragmentos de un esquema procedentes demúltiples fuentes, y para la sustitución de elementos.

La Sección 5 cubre características más avanzadas, incluyendo un mecanismo paraespecificar unicidad entre atributos y elementos, un mecanismo para la utilización de tiposentre distintos espacios de nombres, un mecanismo para extender tipos basados enespacios de nombres, y una descripción de cómo los documentos son validados.

Además de las secciones descritas, los fundamentos contienen un número de apéndicesque proporcionan información detallada de referencia sobre tipos simples y un lenguaje deexpresiones regulares.

Estos Fundamentos son un documento no-normativo, lo que significa que no proporcionauna especificación definitiva del lenguaje Esquema XML (desde el punto de vista delW3C). Los ejemplos y el resto de material explicativo de este documento se proporcionancomo ayuda para entender el Esquema XML, pero no siempre dan respuestas definitivas.En tales casos, necesitarás referirte a la especificación del Esquema XML, y para ayudarteen esto, te proporcionamos muchos enlaces que apuntan a las partes relevantes de laespecificación. De forma más específica, los elementos del Esquema XML mencionados enel texto de los Fundamentos están enlazados a un índice de nombres de elementos yatributos, y una tabla resumen de tipos de datos, ubicadas al final de estos Fundamentos.La tabla y el índice contienen enlaces a las secciones relevantes de las partes 1 y 2 delEsquema XML.

�

2 Conceptos Básicos: Hoja de Pedido

El propósito de un esquema es definir una clase de documentos XML, y por tanto eltérmino "documento instancia" se usa a menudo para describir un documento queconforma con un esquema en particular. De hecho, ni las instancias ni los esquemasnecesitan existir como documentos per se -- pueden existir como flujos de bytes enviadosentre aplicaciones, como campos en un registro de una base de datos, o como coleccionesde XML Infoset "Elementos de Información" -- pero para simplificar estos fundamentos,hemos preferido referirnos a las instancias y esquemas como si fuesen documentos yficheros.

Empecemos considerando un documento instancia en un fichero llamado po.xml . Describeuna hoja de pedido� generada por un pedido de productos para el hogar y una aplicaciónde facturación:

Hoja de Pedido, po.xml

<?xml version="1.0"?><hojaPedido fechaPedido="1999-10-20"> <enviarA pais="EEUU"> <nombre>Alice Smith</nombre>


4 de 57 16/01/2014 21:41

<calle>123 Maple Street</calle> <ciudad>Mill Valley</ciudad> <estado>CA</estado> <zip>90952</zip> </enviarA> <facturarA pais="EEUU"> <nombre>Robert Smith</nombre> <calle>8 Oak Avenue</calle> <ciudad>Old Town</ciudad> <estado>PA</estado> <zip>95819</zip> </facturarA> <comentario>¡Deprisa, mi césped parece una selv a!</comentario> <elementos> <elemento numProducto="872-AA"> <nombreProducto>Cortacesped</nombreProd ucto> <cantidad>1</cantidad> <precioEEUU>148.95</precioEEUU> <comentario>Confirmar que es eléctrico< /comentario> </elemento> <elemento numProducto="926-AA"> <nombreProducto>Monitor para bebes</nom breProducto> <cantidad>1</cantidad> <precioEEUU>39.98</precioEEUU> <fechaEnvio>1999-05-21</fechaEnvio> </elemento> </elementos></hojaPedido>

La hoja de pedido consiste de un elemento principal, hojaPedido , y los subelementosenviarA , facturarA , comentario , y elementos . Estos subelementos (excepto comentario )además contienen otros subelementos, y así, hasta que un subelemento como precioEEUU

contiene un número en vez de más subelementos. Los elementos que contienensubelementos o tienen atributos son denominados tipos complejos, mientras que loselementos que contienen números (y cadenas, y fechas, etc.) pero no contienensubelementos se denominan tipos simples. Algunos elementos tienen atributos; losatributos siempre tienen tipos simples.

Los tipos complejos en el documento instancia, y algunos de los tipos simples, estándefinidos en el esquema para hojas de pedido. Los demás tipos simples están definidoscomo parte del repertorio de tipos simples predefinidos del Esquema XML.

Antes de continuar examinando el esquema de la hoja de pedido, nos pararemosbrevemente para mencionar la asociación entre el documento instancia y el esquema de lahoja de pedido. Como puedes ver inspeccionando el documento instancia, el esquema dela hoja de pedido no es mencionado. No es necesario que una instancia se refiera a unesquema, y aunque muchas lo harán, hemos decidido mantener la simplicidad en estaprimera sección, y asumir que cualquier procesador del documento instancia puedeobtener el esquema de la hoja de pedido sin ninguna información adicional del documentoinstancia. En secciones posteriores, presentaremos mecanismos explícitos para asociarinstancias y esquemas.

2.1 El Esquema de la Hoja de Pedido

El esquema de la hoja de pedido está contenido en el archivo po.xsd :

El Esquema de la Hoja de Pedido , po.xsd

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSc hema"> <xsd:annotation> <xsd:documentation xml:lang="es"> Esquema de hoja de pedido para Example.com. Copyright 2000 Example.com. Todos los derechos r eservados. </xsd:documentation> </xsd:annotation>


5 de 57 16/01/2014 21:41

<xsd:element name="hojaPedido" type="TipoHojaPedid o"/> <xsd:element name="comentario" type="xsd:string"/ > <xsd:complexType name="TipoHojaPedido"> <xsd:sequence> <xsd:element name="enviarA" type="direccionEEU U"/> <xsd:element name="facturarA" type="direccionEEU U"/> <xsd:element ref="comentario" minOccurs="0"/> <xsd:element name="elementos" type="Elementos"/> </xsd:sequence> <xsd:attribute name="fechaPedido" type="xsd:date" /> </xsd:complexType> <xsd:complexType name="direccionEEUU"> <xsd:sequence> <xsd:element name="nombre" type="xsd:string"/> <xsd:element name="calle" type="xsd:string"/> <xsd:element name="ciudad" type="xsd:string"/> <xsd:element name="estado" type="xsd:string"/> <xsd:element name="zip" type="xsd:decimal"/> </xsd:sequence> <xsd:attribute name="pais" type="xsd:NMTOKEN" fix ed="EEUU"/> </xsd:complexType> <xsd:complexType name="Elementos"> <xsd:sequence> <xsd:element name="elemento" minOccurs="0" maxOc curs="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="nombreProducto" type="xsd: string"/> <xsd:element name="cantidad"> <xsd:simpleType> <xsd:restriction base="xsd:positiveInteger" > <xsd:maxExclusive value="100"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="precioEEUU" type="xsd:deci mal"/> <xsd:element ref="comentario" minOccurs="0"/ > <xsd:element name="fechaEnvio" type="xsd:date " minOccurs="0"/> </xsd:sequence> <xsd:attribute name="numProducto" type="SKU" u se="required"/> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType>   <xsd:simpleType name="SKU"> <xsd:restriction base="xsd:string"> <xsd:pattern value="\d{3}-[A-Z]{2}"/> </xsd:restriction> </xsd:simpleType></xsd:schema>

El esquema de la hoja de pedido consiste de un elemento schema y una variedad desubelementos, los más notables, element [elemento] , complexType [tipo complejo] , ysimpleType [tipo simple] que determinan la aparición de elementos y su contenido endocumentos instancia.

Cada uno de los elementos del esquema tiene el prefijo xsd: que está asociado con elespacio de nombres del Esquema XML a través de la declaración,xmlns:xsd="http://www.w3.org/2001/XMLSchema" , que aparece en el elemento schema. Elprefijo xsd: es usado por convención para denotar el espacio de nombres del EsquemaXML, aunque puede utilizarse cualquier prefijo. El mismo prefijo, y por tanto la mismaasociación, también aparece en los nombres de los tipos simples predefinidos, por ejemploxsd: string . El propósito de la asociación es identificar los elementos y tipos simples comopertenecientes al vocabulario del lenguaje Esquema XML y no al vocabulario del autor delesquema. Por consideración a la claridad en el texto, sólo mencionamos los nombres deelementos y tipos simples (p.e. simpleType ), y omitimos el prefijo.


6 de 57 16/01/2014 21:41

2.2 Definiciones de Tipos Complejos, Declaración de Elementos y Atributos

En el Esquema XML, existe una diferencia básica entre los tipos complejos que permitenelementos en su contenido y que pueden tener atributos, y los tipos simples que nopueden tener contenido de elementos ni pueden tener atributos.

También existe una gran distinción entre definiciones que crean tipos nuevos (ya seansimples o complejos), y declaraciones que posibilitan que elementos y atributos connombre y tipos específicos (ya sean simples o complejos) aparezcan en documentosinstancia. En esta sección, nos centramos en la definición de tipos complejos y loselementos y atributos que aparecen en ellos.

Los tipos complejos nuevos se definen utilizando el elemento complexType y talesdefiniciones contienen típicamente un conjunto de declaraciones de elementos, referenciasa elementos, y declaraciones de atributos. Las declaraciones no son tipos en sí mismas, sino más bien una asociación entre un nombre y unas restricciones que dirigen la aparienciade ese nombre en documentos gobernados por el esquema asociado. Los elementos sedeclaran utilizando el elemento element , y los atributos se declaran utilizando el elementoattribute . Por ejemplo, direccionEEUU está definido como un tipo complejo, y dentro de ladefinición de direccionEEUU vemos cinco declaraciones de elementos y una declaración deatributo:

Definición del Tipo direccionEEUU

<xsd:complexType name="direccionEEUU"> <xsd:sequence> <xsd:element name="nombre" type="xsd:string"/> <xsd:element name="calle" type="xsd:string"/> <xsd:element name="ciudad" type="xsd:string"/> <xsd:element name="estado" type="xsd:string"/> <xsd:element name="zip" type="xsd:decimal"/> </xsd:sequence> <xsd:attribute name="pais" type="xsd:NMTOKEN" fi xed="EEUU"/> </xsd:complexType>

La consecuencia de esta definición es que cualquier elemento que aparezca en lainstancia cuyo tipo sea direccionEEUU (p.e. enviarA en po.xml ) debe consistir de cincoelementos y un atributo. Estos elementos deben denominarse nombre , calle , ciudad ,estado y zip como se especifica según los valores de los atributos name en susdeclaraciones, y los elementos deben aparecen en la misma secuencia (orden) en la queson declarados. Los cuatro primeros elementos contendrán una cadena de caracterescada uno, y el quinto contendrá un número. El elemento cuyo tipo ha sido declarado comodireccionEEUU puede aparecer con un atributo llamado pais que debe contener la cadenaEEUU.

La definición de direccionEEUU contiene declaraciones que solamente son de los tipossimples: string , decimal y NMTOKEN. Por contra, la definición de TipoHojaPedido contienedeclaraciones de elementos que son de tipos complejos, p.e. direccionEEUU , aunque hayque resaltar que ambas declaraciones hacen uso del mismo atributo type para identificar eltipo, sin importar que el tipo sea simple o complejo.

Definición del TipoHojaPedido


7 de 57 16/01/2014 21:41

<xsd:complexType name="TipoHojaPedido"> <xsd:sequence> <xsd:element name="enviarA" type="direccionEEU U"/> <xsd:element name="facturarA" type="direccionEEU U"/> <xsd:element ref="comentario" minOccurs="0"/> <xsd:element name="elementos" type="Elementos"/> </xsd:sequence> <xsd:attribute name="fechaPedido" type="xsd:date" /> </xsd:complexType>

Al definir TipoHojaPedido , dos de las declaraciones de elementos, las de enviarA yfacturarA , asocian elementos diferentes con el mismo tipo complejo, llamadodireccionEEUU . La consecuencia de esta definición es que cualquier elemento queaparezca en un documento instancia (p.e. po.xml ) cuyo tipo sea TipoHojaPedido , debetener elementos llamados enviarA y facturarA , y cada uno de ellos debe contener loscinco subelementos (nombre , calle , ciudad , estado y zip ) que fueron declarados comoparte de direccionEEUU . Los elementos enviarA y facturarA deben tener también elatributo pais que fue declarado como parte de direccionEEUU .

La definición de TipoHojaPedido contiene una declaración de atributo fechaPedido que,como la declaración del atributo pais , es de un tipo simple. De hecho, todas lasdeclaraciones de atributos deben referenciar a tipos simples porque, a diferencia de lasdeclaraciones de elementos, los atributos no pueden contener otros elementos o atributos.

Cada una de las declaraciones de elementos que hemos descrito hasta ahora tieneasociado el nombre de un tipo definido. A veces es preferible utilizar un elemento existenteen vez de declarar un elemento nuevo, por ejemplo:

<xsd:element ref="comentario" minOccurs="0"/>

Esta declaración hace referencia a un tipo existente, comentario , que fue declarado enalguna otra parte del esquema de la hoja de pedido. En general, el valor del atributo ref

debe hacer referencia a un elemento global, es decir, uno que ha sido declarado bajo elschema y no como parte de una declaración de un tipo complejo. La consecuencia de estadeclaración es que un elemento denominado comentario puede aparece en un documentoinstancia, y su contenido debe ser coherente con el tipo de ese elemento, en este caso,string .

2.2.1 Restricciones de Ocurrencia

El elemento comentario es opcional dentro de TipoHojaPedido porque el valor del atributominOccurs en su declaración es igual a 0. En general, se requiere la aparición de unelemento cuando el valor de minOccurs es 1 ó mayor. El número máximo de veces quepuede aparecer un elemento es determinado por el valor del atributo maxOccurs en sudeclaración. Este valor puede ser un entero positivo como 41, o el término unbounded [sinlímite] para indicar que no existe un número máximo de ocurrencias. El valor por defectode ambos atributos, el minOccurs y el maxOccurs es 1. Así, cuando un elemento comocomentario es declarado sin un atributo maxOccurs , el elemento no puede aparecer más deuna vez. Asegúrate de que si sólo especificas un valor para el atributo minOccurs , es menoro igual que el valor por defecto del atributo maxOccurs , es decir, es 0 ó 1. De forma similar,si sólo especificas un valor para el atributo maxOccurs , debe ser mayor o igual que el valorpor defecto de minOccurs , es decir, 1 o mayor. Si ambos atributos son omitidos, el elementodebe aparecer exactamente una vez.

Los atributos pueden aparecer una vez o ninguna, pero ningún otro número de veces, poreso la sintaxis para especificar ocurrencias de atributos es diferente que la sintaxis paraelementos. En particular, los atributos pueden ser declarados con un atributo use paraindicar si el atributo es required [requerido] (ver por ejemplo, la declaración del atributo


8 de 57 16/01/2014 21:41

numProducto en po.xsd ), optional [opcional], o incluso prohibited [prohibido].

Los valores por defecto de elementos y atributos son declarados utilizando el atributodefault [defecto], aunque este atributo tiene una consecuencia diferente en cada caso.Cuando un atributo es declarado con un valor por defecto, el valor del atributo es aquelque aparece en como valor del atributo en un documento instancia, si el atributo noaparece en el documento instancia, el procesador del esquema iguala el atributo al valordel atributo default . Hay que resaltar que los valores por defecto de los atributos, sólotienen sentido si los propios atributos son opcionales, por lo que es un error especificar ala vez un valor por defecto y cualquier valor distinto de optional para use .

El procesador de esquemas trata a los elementos por defecto de forma un poco diferente.Cuando un elemento es declarado con un valor por defecto, el valor del elemento escualquier valor que aparece como contenido del elemento en un documento instancia, si elelemento aparece sin contenido, el procesador de esquemas iguala el elemento al valordel atributo default . De todas formas, si el elemento no aparece en el documentoinstancia, el procesador de esquemas no da ningún valor al elemento. En resumen, ladiferencia de tratamiento entre atributos y elementos por defecto es: las valores por defectode los atributos se aplican cuando éstos no están presentes, y los valores por defecto delos elementos se aplican cuando éstos están vacíos.

El atributo fixed [fijo] se utiliza en declaraciones de elementos y atributos para asegurarque los elementos y atributos son igualados a valores particulares. Por ejemplo, po.xsd

contiene una declaración para el atributo pais , que se declara con valor fixed igual a EEUU.Esta declaración significa que la aparición de un atributo pais en un documento instanciaes opcional (el valor por defecto de use es optional ), aunque si el atributo aparece, suvalor debe ser EEUU. Hay que resaltar que los conceptos de un valor fijo y de un valor pordefecto son mutuamente excluyentes, y por tanto es un error para una declaracióncontener ambos atributos fixed y default .

Los valores de los atributos utilizados en declaraciones de elementos y atributos pararestringir sus ocurrencias se resumen en la Tabla 1.

Tabla 1. Restricciones de Ocurrencia para Elementos y Atributos

Elementos(minOccurs ,

maxOccurs ) fixed ,default��

Atributosuse, fixed ,

defaultNotas

(1, 1) -, - required, -, -el elemento/atributo debe aparece una vez, puedetener cualquier valor

(1, 1) 37, -required, 37,

-el elemento/atributo debe aparecer una vez, su valordebe ser 37

(2, unbounded) 37, - n/a

el elemento debe aparecer dos veces o más, su valordebe ser 37; en general, los valores de minOccurs ymaxOccurs deben ser enteros positivos, y el demaxOccurs también puede ser "unbounded"

(0, 1) -, - optional, -, -el elemento/atributo puede aparecer una vez, puedetener cualquier valor

(0, 1) 37, -optional, 37,

-

el elemento/atributo puede aparecer una vez, siaparece su valor debe ser 37, si no aparece su valores 37

(0, 1) -, 37optional, -,

37

el elemento/atributo puede aparecer una vez; si noaparece su valor es 37, en otro caso su valor es eldado


9 de 57 16/01/2014 21:41

(0, 2) -, 37 n/a

el elemento puede aparecer una vez, dos, oninguna; si el elemento no aparece no es aplicable;si aparece y es vacío su valor es 37; en otro caso esel valor dado; en general, los valores de minOccurs ymaxOccurs deben ser enteros positivos, y el demaxOccurs también puede ser "unbounded"

(0, 0) -, -prohibited, -,

-el elemento/atributo no debe aparecer

Nótese que ni minOccurs, maxOccurs, ni use pueden aparecer en las declaraciones deelementos y atributos globales.

�

2.2.2 Elementos y Atributos Globales

Los elementos y atributos globales, son creados por declaraciones que aparecen comohijos del elemento schema. Una vez declarado, un elemento o atributo global puede serreferenciado en una o más declaraciones utilizando el atributo ref según se ha descritoarriba. Una declaración que hace referencia a un elemento global posibilita que elelemento aparezca en el documento instancia en el contexto de la declaración referente.Así, por ejemplo el elemento comentario aparece en po.xml al mismo nivel que loselementos enviarA , facturarA y elementos porque la declaración que referencia acomentario aparece en la definición del tipo complejo al mismo nivel que las declaracionesde los otros tres elementos.

La declaración de un elemento global también posibilita que el elemento aparezca en elnivel raíz de un documento instancia. Así, hojaPedido , que es declarado como un elementoglobal en po.xsd , puede aparecer como el elemento raíz en po.xml . Hay que hacer notarque este razonamiento también permitirá a un elemento comentario aparecer como elelemento raíz en un documento como po.xml .

Hay un número de advertencias que atañen al uso de elementos y atributos globales. Unaadvertencia es que las declaraciones globales no pueden contener referencias; lasdeclaraciones globales deben identificar tipos simples y complejos directamente. Enconcreto, las declaraciones globales no pueden contener el atributo ref , deben utilizar elatributo type (o, como describiremos en breve, estar seguidas de una definición de tipoanónimo). Una segunda advertencia es que las restricciones de cardinalidad no puedenser colocadas en declaraciones globales, aunque pueden ser colocadas en declaracioneslocales que referencien a declaraciones globales. En otras palabras, las declaracionesglobales no pueden contener los atributos minOccurs, maxOccurs, o use.

2.2.3 Conflictos de Nombres

Hemos descrito como definir tipos complejos (p.e. TipoHojaPedido ), declarar elementos(p.e. hojaPedido ) y declarar atributos (p.e. fechaPedido ) . Estas actividades generalmenteincluyen la asignación de nombres, y así surge la siguiente pregunta: ¿Qué ocurre si ledamos el mismo nombre a dos cosas diferentes? La respuesta depende de las dos cosasen cuestión, aunque en general, cuanto más parecidas son ambas cosas, másprobabilidades de que exista un conflicto.

He aquí algunos ejemplos para ilustrar cuando los nombres iguales causan problemas. Silas dos cosas son tipos, digamos que definimos un tipo complejo llamado EstadoEEUU yun tipo simple llamado EstadoEEUU, existe un conflicto. Si las dos cosas son un tipo y unelemento o atributo, digamos que definimos un tipo complejo llamado DireccionEEUU yque declaramos un elemento llamado DireccionEEUU, no existe conflicto. Si las dos cosasson elementos dentro de tipos diferentes, (es decir, no son elementos globales), digamos


10 de 57 16/01/2014 21:41

que declaramos un elemento llamado nombre como parte del tipo DireccionEEUU y unsegundo elemento llamado nombre como parte del tipo Elementos, no existe conflicto.(Tales elementos son a menudo denominados declaraciones de elementos locales).Finalmente, si las dos cosas son tipos y tú defines una y el Esquema XML ha definido laotra, digamos que tú has definido un tipo simple llamado decimal, no existe conflicto. Larazón de esta contradicción aparente en el último ejemplo es que los dos tipos pertenecena espacios de nombres distintos. Exploraremos el uso de espacios de nombre en losesquemas en una sección posterior.

2.3 Tipos Simples

El esquema de la hoja de pedido declara varios elementos y atributos que tienen tipossimples. Algunos de estos tipos simples como string y decimal , están predefinidos en elEsquema XML, mientras que otros son derivados de los predefinidos. Por ejemplo elatributo numProducto tiene un tipo llamado SKU (Stock Keeping Unit [Código deAlmacenaje]) que se deriva de string . Tanto los tipos simples como sus derivacionespueden ser utilizados en todas las declaraciones de elementos y atributos. La Tabla 2 listatodos los atributos simples predefinidos en el Esquema XML, junto con ejemplos de losdiferentes tipos.

Tabla 2. Tipos Simples Predefinidos en el Esquema X ML

Tipo Simple Ejemplos (delimitados por comas) Notas

string Confirmar que es eléctrico �normalizedString Confirmar que es eléctrico ver (3)

token Confirmar que es eléctrico ver (4)

byte -1, 126 ver (2)

unsignedByte 0, 126 ver (2)�base64Binary GpM7 �hexBinary 0FB7 �integer -126789, -1, 0, 1, 126789 ver (2)

positiveInteger 1, 126789 ver (2)

negativeInteger -126789, -1 ver (2)

nonNegativeInteger 0, 1, 126789 ver (2)

nonPositiveInteger -126789, -1, 0 ver (2)

int -1, 126789675 ver (2)

unsignedInt 0, 1267896754 ver (2)

long -1, 12678967543233 ver (2)

unsignedLong 0, 12678967543233 ver (2)

short -1, 12678 ver (2)

unsignedShort 0, 12678 ver (2)

decimal -1.23, 0, 123.4, 1000.00 ver (2)

float-INF, -1E4, -0, 0, 12.78E-2, 12, INF,NaN

equivalente a punto flotantede precisión simple de32-bit, NaN es "not anumber" ["no es unnúmero"], ver (2)

double-INF, -1E4, -0, 0, 12.78E-2, 12, INF,NaN

equivalente a punto flotantede doble precisión 64-bit,ver (2)


11 de 57 16/01/2014 21:41

booleantrue, false1, 0

[verdadero, falso]

time 13:20:00.000, 13:20:00.000-05:00 ver (2)

dateTime 1999-05-31T13:20:00.000-05:00

31 de Mayo de 1999 a las1.20pm Hora Estándar dela Costa Este que va 5horas por detrás de la HoraUniversal, ver (2)

duration P1Y2M3DT10H30M12.3S

1 año, 2 meses, 3 días, 10horas, 30 minutos, 2meses, 3 días, 10 horas, 30minutos, y 12.3 segundos

date 1999-05-31 ver (2)

gMonth --05-- Mayo, ver (2) (5)

gYear 1999 1999, ver (2) (5)

gYearMonth 1999-02el mes de Febrero de 1999,sin importar el número dedías, ver (2) (5)

gDay ---31 el día 31, ver (2) (5)

gMonthDay --05-31cada 31 de Mayo, ver (2)(5)

Name enviarA tipo Nombre de XML 1.0

QName po:direccionEEUUQName de Espacio deNombres XML

NCName direccionEEUU

NCName del Espacio deNombres XML, p.e. unQName sin el prefijo ni losdos puntos

anyURIhttp://www.example.com/,http://www.example.com/doc.html#ID5 �

language en-GB, en-US, frvalores válidos paraxml:lang según estádefinido en XML 1.0

ID � atributo tipo ID XML 1.0, ver(1)

IDREF � atributo tipo IDREF XML1.0, ver (1)

IDREFS � atributo tipo IDREFS XML1.0, ver (1)

ENTITY � atributo tipo ENTITY XML1.0, ver (1)

ENTITIES � atributo tipo ENTITIES XML1.0, ver (1)

NOTATION � atributo tipo NOTATIONXML 1.0, ver (1)

NMTOKENUS,Brasil

atributo tipo NMTOKENXML 1.0, ver (1)

NMTOKENSUS UK,Brasil Canada Mexico

atributo tipo NMTOKENSXML 1.0, p.e. una lista deNMTOKENs separada porespacios en blanco, ver (1)


12 de 57 16/01/2014 21:41

Notas: (1) Para mantener la compatibilidad entre el Esquema XML y los DTD de XML 1.0, los tipos simplesID, IDREF, IDREFS, ENTITY, ENTITIES, NOTATION, NMTOKEN, NMTOKENS deberían ser usados sólo enatributos. (2) Un valor de este tipo puede ser representado por más de un forma léxica, p.e. 100 y 1.0E2 sonambos formatos válidos flotantes que representan "un ciento". De todas formas, han sido establecidas reglaspara este tipo que definen una forma léxica canónica, ver el Esquema XML Parte 2. (3) Los caracteres nuevalínea, tabulador y retorno de carro en un tipo normalizedString son convertidos a caracteres de espacio enblanco antes del procesamiento del esquema. (4) Como en normalizedString, los espacios en blancoadyacentes son comprimidos a un sólo espacio en blanco, y los espacios en blanco de delante y detrás soneliminados. (5) El prefijo "g" señala periodos de tiempo en el calendario Gregoriano.

Los tipos simples nuevos se definen derivándolos de los tipos simples existentes (lospredefinidos y derivados). En particular, podemos derivar un tipo simple nuevorestringiendo un tipo simple existente, en otras palabras, el rango legal es un subconjuntodel rango de valores existente del tipo. Se utiliza el elemento simpleType [tipoSimple] paradefinir y nombrar el tipo simple nuevo. Se utiliza el elemento restriction [restricción] paraindicar el tipo (base) existente y para identificar las "propiedades" que restringen el rangode valores. Se proporciona una lista de propiedades completa en el Apéndice B.

Supongamos que queremos crear un tipo nuevo de entero miEntero llamado cuyo rangode valores esté entre 10000 y 99999 (inclusive). Basamos nuestra definición en el tipopredefinido integer [entero], cuyo rango de valores también incluye enteros menores que10000 y mayores que 99999. Para definir miEntero , restringimos el rango del tipo baseinteger empleando dos propiedades denominadas minInclusive y maxInclusive :

Definición de miEntero, rango de 10000-99999

<xsd:simpleType name="miEntero"> <xsd:restriction base="xsd:integer"> <xsd:minInclusive value="10000"/> <xsd:maxInclusive value="99999"/> </xsd:restriction></xsd:simpleType>

El ejemplo muestra una combinación particular de un tipo base de dos propiedadesutilizadas para definir miEntero , pero un vistazo a la lista de tipos y propiedadespredefinidas (Apéndice B) podría sugerir otras posibles combinaciones.

El esquema de la hoja de pedido contiene otro ejemplo, más elaborado, de una definiciónde tipo simple. Un tipo simple nuevo llamado SKU se deriva (por restricción) del tipo simplestring [cadena]. Más aún, restringimos los valores de SKU utilizando una propiedadllamada pattern [patrón] en conjunción con la expresión regular "\d{3}-[A-Z]{2} " que selee como "tres dígitos seguidos de un guión seguido de dos caracteres ASCII enmayúsculas":

Definición del Tipo Simple "SKU"

<xsd:simpleType name="SKU"> <xsd:restriction base="xsd:string"> <xsd:pattern value="\d{3}-[A-Z]{2}"/> </xsd:restriction></xsd:simpleType>

Este lenguaje de expresiones regulares se describe en mayor profundidad en el ApéndiceD.

El Esquema XML define quince propiedades que están listadas en el Apéndice B. Entreellas, la propiedad enumeration [enumeración] es particularmente útil y pude ser usadapara restringir los valores de casi todos los tipos simples, excepto el boolean [booleano]. Lapropiedad enumeration limita un tipo simple a un conjunto de valores distintos. Porejemplo, podemos usar la propiedad enumeration para definir un tipo simple nuevo


13 de 57 16/01/2014 21:41

llamado estadoEEUU , derivado de string , cuyo valor debe ser una de las abreviacionesestándar de estado de EEUU:

Utilización de la Propiedad Enumeration

<xsd:simpleType name="estadoEEUU"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="AK"/> <xsd:enumeration value="AL"/> <xsd:enumeration value="AR"/>  </xsd:restriction></xsd:simpleType>

estadoEEUU , sería un buen sustituto para el tipo string utilizado actualmente en ladeclaración del elemento estado . Haciendo esta sustitución, los valores legales de unelemento estado , es decir, los subelementos estado de facturarA y enviarA , estaríanlimitados a alguno de AK, AL, AR, etc. Nótese que los valores especificados para un tipoparticular deben ser únicos.

2.3.1 Tipos Lista

El Esquema XML tiene el concepto de tipo lista, además de los llamados tipos atómicosque son la mayoría de los tipos listados en la Tabla 2. (Los tipos atómicos, tipos lista, y lostipos unión descritos en la próxima sección son llamados colectivamente tipos simples). Elvalor de un tipo atómico es indivisible desde la perspectiva del Esquema XML. Por ejemplo,el NMTOKEN de valor EEUU es indivisible en el sentido en que ninguna parte de EEUU, como elcarácter "U", tiene ningún significado por si misma. Por contra, los tipos lista estáncompuestos de secuencias de tipos atómicos y consecuentemente las partes de unasecuencia (los "átomos") tienen sentido. Por ejemplo, NMTOKENS es un tipo lista, y unelemento de ese tipo sería una lista de NMTOKEN's delimitados por espacio en blanco, talescomo "EEUU UK FR" . El Esquema XML tiene tres tipos de lista predefinidos, sonNMTOKENS, IDREFS, y ENTITIES .

Además de utilizar los tipos de lista predefinidos, puedes crear nuevos tipos de listas porderivación de los tipos atómicos existentes. (No puedes crear tipos de lista partiendo detipos de lista existentes, ni de tipos complejos). Por ejemplo, para crear una lista deelementos miEntero :

Crear una Lista de elementos miEntero

<xsd:simpleType name="listaDeMisEnteros"> <xsd:list itemType="miEntero"/></xsd:simpleType>

Y un elemento en un documento instancia cuyo contenido conforme con el delistaDeMisEnteros es:

<listaDeMisEnteros>20003 15037 95977 95945</listaDe MisEnteros>

Pueden aplicarse varias propiedades a los tipos lista: length [longitud], minLength [longitudmínima], maxLength [longitud máxima], y enumeration [enumeración]. Por ejemplo, paradefinir una lista de seis estados exactamente (SeisEstadosEEUU ), definimos primero un tipode lista nuevo llamado ListaEstadosEEUU a partir de EstadoEEUU), y entonces derivamosSeisEstadosEEUU , restringiendo ListaEstadosEEUU a sólo seis elementos:

Tipo Lista para Seis Estados EEUU


14 de 57 16/01/2014 21:41

<xsd:simpleType name="ListaEstadosEEUU"> <xsd:list itemType="estadoEEUU"/></xsd:simpleType><xsd:simpleType name="SeisEstadosEEUU"> <xsd:restriction base="ListaEstadosEEUU"> <xsd:length value="6"/> </xsd:restriction></xsd:simpleType>

Los elementos cuyo tipo sea SeisEstadosEEUU deben tener seis elementos, y cada uno delos seis elementos, debe ser uno de los valores (atómicos) del tipo enumerado EstadoEEUU ,por ejemplo:

<seisEstados>PA NY CA NY LA AK</seisEstados>

Resaltemos que es posible derivar un tipo lista del tipo atómico string [cadena decaracteres]. Sin embargo, un string puede contener espacios en blanco, y los espacios enblanco delimitan los elementos de una lista, por lo que deberías tener cuidado al definirtipos lista cuyo tipo base sea el string . Por ejemplo, supón que hemos definido un tipolista cuya propiedad length es igual a 3, y de tipos base string , entonces la siguiente listade tres elementos es legal:

Asia Europa Africa

Pero la siguiente lista de tres elementos no es legal:

Asia Europa America Latina

Incluso aunque "America Latina" puede existir como una cadena de caracteres simplefuera de la lista, cuando se incluye en la lista, el espacio en blanco entre America y Latinacrea un cuarto elemento, y por eso el último ejemplo no conformará con el tipo lista de 3elementos.

2.3.2 Tipos Unión

Los tipos atómicos y los tipos lista posibilitan el que el valor de un elemento o atributo seade una o más instancias de un tipo atómico. Por contra, un tipo unión facilita el que el valorde un elemento o atributo sea de una o más instancias de un tipo formado por la unión demúltiples tipos atómicos y tipos lista. Para ilustrar esto, creemos un tipo unión pararepresentar los estados Americanos como abreviaciones de letras únicas o listas decódigos numéricos. El tipo unionZips se forma a partir de un tipo atómico y un tipo lista:

Tipo Unión para Códigos

<xsd:simpleType name="unionZips"> <xsd:union memberTypes="estadoEEUU listaDeMisEnte ros"/></xsd:simpleType>

Cuando definimos un tipo unión, el atributo memberTypes [tiposMiembro] es una lista detodos los tipos de la unión.

Ahora, asumiendo que hemos declarado un elemento llamado zips de tipo unionZips ,instancias válidas del elemento son:

<zips>CA</zips><zips>95630 95977 95945</zips>


15 de 57 16/01/2014 21:41

<zips>AK</zips>

Dos propiedades, pattern y enumeration , pueden ser aplicadas a un tipo unión.

2.4 Definiciones de Tipos Anónimos

Los Esquemas pueden ser construidos definiendo conjuntos de tipos con nombre talescomo TipoHojaPedido y entonces declarando elementos como hojaPedido que referenciana los tipos usando la construcción type = . Este estilo de construcción del esquema esdirecto pero puede ser engorroso, especialmente si se definen muchos tipos que sonreferenciados una sola vez y contienen muy pocas restricciones. En estos casos, un tipopuede ser definido de forma más breve como un tipo anónimo, lo que evita la sobrecargade tener que nombrarlo y referenciarlo explícitamente.

La definición del tipo Elementos en po.xsd contiene declaraciones de dos elementos queutilizan tipos anónimos (elemento y cantidad ). En general, puedes identificar tiposanónimos por la falta de un type = en una declaración de elemento (o atributo), y por lapresencia de una declaración de tipo con nombre (simple o compleja):

Dos Definiciones de Tipo Anónimo

<xsd:complexType name="Elementos"> <xsd:sequence> <xsd:element name="elemento" minOccurs="0" maxOcc urs="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="nombreProducto" type="xsd:s tring"/> <xsd:element name="cantidad"> <xsd:simpleType> <xsd:restriction base="xsd:positiveInteger"> <xsd:maxExclusive value="100"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="precioEEUU" type="xsd:deci mal"/> <xsd:element ref="comentario" minOccurs="0"/ > <xsd:element name="fechaEnvio" type="xsd:date" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="numProducto" type="SKU" us e="required"/> </xsd:complexType> </xsd:element> </xsd:sequence></xsd:complexType>

En el caso del elemento elemento , tiene un tipo anónimo complejo formado por loselementos nombreProducto , cantidad , precioEEUU , comentario , y fechaEnvio , y un atributollamado numProducto . En el caso del elemento cantidad , tiene un tipo anónimo simplederivado de integer cuyo valor está comprendido entre 1 y 99.

2.5 Contenido de Elementos

El esquema de la hoja de pedido tiene muchos ejemplos de elementos que contiene otroselementos (p.e. elementos ), elementos con atributos que contienen otros elementos (p.e.enviarA ), y elementos que contienen sólo un valor de tipo simple (p.e. precioEEUU ). Detodas formas, no hemos visto ningún elemento que contenga atributos pero que contengasólo un valor de tipo simple, ni tampoco hemos visto un elemento que contenga otroselementos mezclados con contenido de caracteres, ni hemos visto elementos sincontenido. En esta sección examinaremos estas variaciones en el contenido de losmodelos de elementos.

2.5.1 Tipos Complejos desde Tipos Simples


16 de 57 16/01/2014 21:41

Permítenos considerar primero cómo declarar un elemento que tiene un atributo y contieneun valor simple. En un documento instancia, tal elemento debería aparecer como:

<precioInternacional moneda="EUR">423.46</precioInt ernacional>

El esquema de la hoja de pedido declara un elemento precioEEUU que es el punto departida:

<xsd:element name="precioEEUU" type="decimal"/>

Pero, ¿cómo añadimos un atributo a este elemento? Como hemos dicho antes, los tipossimples no pueden tener atributos, y decimal es un tipo simple. Por tanto, debemos definirun tipo complejo que lleve la declaración del atributo. También queremos que el contenidosea del tipo simple decimal . Así que nuestra pregunta original se convierte en ¿cómodefinimos un tipo complejo basado en el tipo simple decimal ? La respuesta es derivar untipo complejo nuevo del tipo simple decimal :

Derivación de un Tipo Complejo a partir de un Tipo Simple

<xsd:element name="precioInternacional"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="xsd:decimal"> <xsd:attribute name="moneda" type="xsd:string" /> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element>

Utilizamos el elemento complexType para comenzar la definición de un nuevo tipo(anónimo). Para indicar que el modelo de contenido del nuevo tipo contiene sólocaracteres y no elementos, utilizamos un elemento simpleContent . Finalmente, derivamosel nuevo tipo extendiendo el tipo simple decimal . La extensión consiste en añadir unatributo moneda utilizando una declaración estándar de atributo. (Hablaremos de laderivación de tipos en detalle en la Sección 4). El elemento precioInternacional

declarado de esta manera aparecerá en una instancia como se muestra en el ejemplo alprincipio de esta sección.

2.5.2 Contenido Mixto

La construcción del esquema de la hoja de pedido puede caracterizarse por elementosque contienen subelementos, y los elementos del nivel más profundo contienen caracteresde datos. El Esquema XML también posibilita la construcción de esquemas en los que loscaracteres pueden aparecer junto con los subelementos, y los caracteres no estánconfinados al más profundo de los niveles.

Para ilustrar esto, considera el siguiente fragmento de una carta de un cliente que utilizaelementos de la hoja de pedido:

Fragmento de Carta de un Cliente

<cuerpoCarta><saludo>Querido Sr.<nombre>Robert Smith</nombre>.</ saludo>Su pedido de <cantidad>1</cantidad> <nombreProducto >Monitor de Bebés</nombreProducto> fue enviado desde nuestroalmacén el <fechaEnvio>1999-05-21</fechaEnvio>. ... .</cuerpoCarta>


17 de 57 16/01/2014 21:41

Nótese que el texto aparece entre los elementos y sus elementos hijo. Específicamente, eltexto aparece entre los elementos saludo , cantidad , nombreProducto y fechaEnvio que sontodos hijos de cuerpoCarta , y el texto aparece alrededor del elemento nombre que es elhijo de un hijo de cuerpoCarta . El siguiente fragmento de un esquema declaracuerpoCarta :

Fragmento de un Esquema para Carta de Cliente

<xsd:element name="cuerpoCarta"> <xsd:complexType mixed="true"> <xsd:sequence> <xsd:element name="saludo"> <xsd:complexType mixed="true"> <xsd:sequence> <xsd:element name="nombre" type="xsd:string"/ > </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="cantidad" type="xsd:pos itiveInteger"/> <xsd:element name="nombreProducto" type="xsd:str ing"/> <xsd:element name="fechaEnvio" type="xsd:dat e" minOccurs="0"/>  </xsd:sequence> </xsd:complexType></xsd:element>

Los elementos que aparecen en la carta del cliente se declaran, y sus tipos se definenutilizando las construcciones de element y complexType que hemos visto anteriormente.Para que sea posible el que aparezcan caracteres entre los elementos hijo decuerpoCarta , el atributo mixed en la definición del tipo se ha puesto a true [verdadero].

Nótese que el modelo en el Esquema XML difiere fundamentalmente del modelo mixed enXML 1.0. En el modelo mixto de Esquema XML, el orden y número de los elementos hijoque aparecen en una instancia debe coincidir en tipo y número con los elementos hijoespecificados en el modelo. Por contra, en el modelo mixto de XML 1.0, el orden y númerode los elementos hijo de la instancia no puede ser restringido. En resumen, el EsquemaXML proporciona validación total de modelos mixtos en contraste con la validación parcialproporcionada por el XML 1.0.

2.5.3 Contenido Vacío

Supongamos que queremos que el elemento precioInternacional contenga la unidad demoneda y el precio como valores de atributos en vez de tenerlos como valores separadosde atributo y contenido. Por ejemplo:

<precioInternacional moneda="EUR" valor="423.46"/>

Tal elemento no tiene ningún contenido; su modelo de contenido es vacío. Para definir unelemento de contenido vacío, esencialmente definimos un tipo que sólo permite elementosen su contenido, pero realmente no declaramos ningún elemento y así conseguimos quesu modelo de contenido sea vacío:

Un Tipo Complejo Vacío

<xsd:element name="precioInternacional"> <xsd:complexType> <xsd:complexContent> <xsd:restriction base="xsd:anyType"> <xsd:attribute name="moneda" type="xsd:string"/ > <xsd:attribute name="valor" type="xsd:decimal" /> </xsd:restriction> </xsd:complexContent>


18 de 57 16/01/2014 21:41

</xsd:complexType></xsd:element>

En este ejemplo, definimos un tipo (anónimo) que tiene complexContent , es decir, sóloelementos. El elemento complexContent indica que tenemos que restringir o extender elmodelo de contenido de un tipo complejo, y la restriction de anyType [cualquierTipo]declara dos atributos pero no presenta ningún contenido para el elemento (ver Sección 4.4para más detalles sobre restricción). El elemento precioInternacional declarado de estaforma puede aparecer legítimamente en una instancia como se muestra en el ejemploanterior.

La sintaxis anterior para un elemento de contenido vacío es relativamente prolija, y esposible declarar el elemento precioInternacional de manera más compacta:

Forma Abreviada para definir un Tipo Complejo Vacío

<xsd:element name="precioInternacional"> <xsd:complexType> <xsd:attribute name="moneda" type="xsd:string"/> <xsd:attribute name="valor" type="xsd:decimal"/> </xsd:complexType></xsd:element>

Esta sintaxis compacta funciona porque un tipo complejo definido sin ningúnsimpleContent o complexContent es interpretado como una forma abreviada para contenidocomplejo que restringe anyType .

2.5.4 anyType [cualquierTipo]

El anyType representa una abstracción llamada el ur-type que es el tipo base del quederivan todos los tipos simples y complejos. Un tipo anyType no restringe su contenido enmodo alguno. Es posible utilizar anyType como otros tipos, por ejemplo:

<xsd:element name="cualquiercosa" type="xsd:anyType "/>

El contenido del elemento declarado de esta manera no está restringido, así que elelemento puede valer 423.46, pero también puede ser cualquier otra secuencia decaracteres, o una mezcla de caracteres y elementos. De hecho, anyType es el tipo pordefecto cuando no se especifica ninguno, así que el ejemplo anterior puede escribirsetambién como:

<xsd:element name="cualquiercosa"/>

Si se necesita contenido de elementos sin restricciones, por ejemplo en el caso deelementos que contienen prosa que requiere marcado embebido para soportarinternacionalización, entonces la declaración por defecto o una forma ligeramenterestringida de ella puede ser apropiada. El tipo text descrito en la Sección 5.5 es unejemplo de un tipo así que es apropiado para tal propósito.

2.6 Anotaciones

El Esquema XML proporciona tres elementos para anotar esquemas para el beneficio delos lectores humanos y de las aplicaciones. En el esquema de la hoja de pedido, hemospuesto descripciones básicas e información de propiedad literaria dentro del elementodocumentation [documentación], que es la ubicación recomendada para el material legiblepor humanos. Recomendamos utilizar el atributo xml:lang con todos los elementos dedocumentation para indicar el lenguaje de la información. Alternativamente, puedes indicar


19 de 57 16/01/2014 21:41

el lenguaje de toda la información en un esquema poniendo un atributo xml:lang en elelemento schema.

El elemento appInfo [información para aplicaciones], que no utilizamos en el esquema dela hoja de pedido, puede utilizarse para proporcionar información para herramientas, hojasde estilo y otras aplicaciones. Un ejemplo interesante de uso de appInfo es un schemaque describe los tipos simples en el documento Esquema XML Parte 2: Tipos de Datos. Lainformación que describe este esquema, p.e. cuyas propiedades son aplicables a tipossimples particulares, se representa dentro de los elementos appInfo , y esta informaciónfue utilizada por una aplicación para generar texto de forma automática para el documentoEsquema XML Parte 2.

Ambos documentation y appInfo aparecen como subelementos de annotation [anotación],el cual puede aparecer por si mismo al principio de la mayoría de construcciones enesquemas. Para ilustrar esto, el siguiente ejemplo muestra elementos annotation queaparecen al principio de una declaración de elemento y una definición de tipo complejo:

Anotaciones en Declaraciones de Elementos y Definic iones de Tipos Complejos

<xsd:element name="precioInternacional"> <xsd:annotation> <xsd:documentation xml:lang="es"> elemento declarado con tipo anónimo </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:annotation> <xsd:documentation xml:lang="es"> tipo anónimo vacío con 2 atributos </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:restriction base="xsd:anyType"> <xsd:attribute name="moneda" type="xsd:string"/ > <xsd:attribute name="valor" type="xsd:decimal" /> </xsd:restriction> </xsd:complexContent> </xsd:complexType></xsd:element>

El elemento annotation puede aparecer también al principio de otras construcciones enesquemas tales como las indicadas por los elementos schema, simpleType , y attribute .

2.7 Construcción de Modelos de Contenido

Todas las definiciones de tipos complejos en el esquema de la hoja de pedido declaransecuencias de elementos que deben aparecer en el documento instancia. La ocurrencia deelementos individuales declarada en los llamados modelos de contenido de esos tipospuede ser opcional, como se indica por un valor de 0 para el atributo minOccurs (p.e. encomentario ), o ser restringidos de otra manera dependiendo de los valores de minOccurs ymaxOccurs . El Esquema XML también proporciona restricciones que se aplican a grupos deelementos que aparecen en el modelo de contenido. Estas restricciones reflejan lasdisponibles en XML 1.0 y añaden algunas más. Recordemos que las restricciones no seaplican a atributos.

El Esquema XML posibilita el que grupos de elementos sean definidos y nombrados, por loque los elementos pueden ser utilizados para construir modelos de tipos complejos(mimetizando el uso común de entidades parámetro en XML 1.0). También puedendefinirse grupos de elementos sin nombre, que junto con elementos en grupos connombre, pueden ser restringidos para aparecer en el mismos orden (secuencia) en el queson declarados. Alternativamente, pueden ser restringidos de forma que sólo uno de loselementos puede aparecer en la instancia.


20 de 57 16/01/2014 21:41

Para ilustrar esto, introducimos dos grupos en la definición de TipoHojaPedido delesquema de la hoja de pedido por los que las hojas de pedido pueden contener o biendirecciones de envío y facturación separadas, o una única dirección para los casos en losque la persona a la que se factura y envía sean la misma:

Condiciones Anidadas y Grupos de Secuencias

<xsd:complexType name="TipoHojaPedido"> <xsd:sequence> <xsd:choice> <xsd:group ref="envioYfacturacion"/> <xsd:element name="direccionEEUUunica" type="dir eccionEEUU"/> </xsd:choice> <xsd:element ref="comentario" minOccurs="0"/> <xsd:element name="elementos" type="Elementos"/> </xsd:sequence> <xsd:attribute name="fechaPedido" type="xsd:date"/ ></xsd:complexType><xsd:group name="envioYfacturacion"> <xsd:sequence> <xsd:element name="enviarA" type="direccionEE UU"/> <xsd:element name="facturarA" type="direccionEE UU"/> </xsd:sequence></xsd:group>

El elemento choice [elección] en un grupo permite que sólo uno de sus hijos aparezca enla instancia. Un hijo es un elemento interior de group [grupo] que referencia al grupollamado envioYfacturacion consistente en la secuencia de elementos enviarA , facturarA ,y el segundo hijo es una direccionEEUUunica . Por tanto, en un documento instancia, elelemento hojaPedido debe contener o bien un elemento enviarA seguido de un elementofacturarA o una direccionEEUUunica . El grupo choice está seguido de las declaracionesde los elementos comentario y elementos y tanto el grupo choice como las declaracionesde los elementos son hijos de el grupo sequence [secuencia]. El efecto de estos grupos esque el elemento o elementos dirección deben estar seguidos por elementos comentario yelementos en ese orden.

Existe una tercera opción para restringir los elementos de un grupo: todos los elementosde un grupo pueden aparecer una vez o ninguna, y pueden aparecer en cualquier orden.El grupo all [todo] (que proporciona una versión simplificada de conector & de SGML)está limitado al nivel más alto de cualquier modelo de contenido. Más aún, los hijos delgrupo deben ser todo elementos individuales (no grupos), y ningún elemento en el modelodebe aparecer más de una vez, es decir, los valores permitidos de minOccurs y maxOccurs

son 0 y 1. Por ejemplo, para permitir que elementos hijo de hojaPedido aparezcan encualquier orden, podríamos redefinir TipoHojaPedido como:

Un Grupo 'All'

<xsd:complexType name="TipoHojaPedido"> <xsd:all> <xsd:element name="enviarA" type="direccion EEUU"/> <xsd:element name="facturarA" type="direccion EEUU"/> <xsd:element ref="comentario" minOccurs="0"/> <xsd:element name="elementos" type="Elementos "/> </xsd:all> <xsd:attribute name="fechaPedido" type="xsd:date" /></xsd:complexType>

Por esta definición, un elemento comentario podría aparecer opcionalmente dentro dehojaPedido , y puede aparecer antes o después que cualquier elemento enviarA , facturarA

y elementos , pero sólo puede aparecer una vez. Más aún, las estipulaciones de un grupoall no nos permiten declarar un elemento como comentario fuera del grupo con el fin deque aparezca más de una vez. El Esquema XML estipula que un grupo all debe aparecercomo hijo único en el nivel más alto del modelo de contenido. En otras palabras, lo


21 de 57 16/01/2014 21:41

siguiente no es legal:

Ejemplo No Legal con un Grupo 'All'

<xsd:complexType name="TipoHojaPedido"> <xsd:sequence> <xsd:all> <xsd:element name="enviarA" type="direccion EEUU"/> <xsd:element name="facturarA" type="direcci onEEUU"/> <xsd:element name="elementos" type="Elementos" /> </xsd:all> <xsd:sequence> <xsd:element ref="comentario" minOccurs="0" ma xOccurs="unbounded"/> </xsd:sequence> </xsd:sequence> <xsd:attribute name="fechaPedido" type="xsd:date"/ ></xsd:complexType>

Finalmente, los grupos con nombre y sin nombre que aparecen en modelos de contenido(representado por group y choice , sequence , all respectivamente) pueden tener atributosminOccurs y maxOccurs . Combinando y anidando los distintos grupos proporcionados por elEsquema XML, y utilizando los valores de minOccurs y maxOccurs , es posible representarcualquier modelo de contenido expresable con un DTD de XML 1.0. Además, el grupo all

proporciona poder expresivo adicional.

2.8 Grupos de Atributos

Supongamos que queremos dar más información acerca de cada elemento en la hoja depedido, por ejemplo, el peso de cada elemento y el modo de envío preferido. Podemosconseguir esto añadiendo las declaraciones de los atributos pesoKg y enviarPor a ladefinición de tipo (anónimo) del elemento elemento :

Añadir Atributos a la Declaración de Tipo Anónima

<xsd:element name="Elemento" minOccurs="0" maxOccur s="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="nombreProducto" type="xsd: string"/> <xsd:element name="cantidad"> <xsd:simpleType> <xsd:restriction base="xsd:positiveInteger"> <xsd:maxExclusive value="100"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="precioEEUU" type="xsd:decima l"/> <xsd:element ref="comentario" minOccurs="0"/> <xsd:element name="fechaEnvio" type="xsd:date" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="numProducto" type="SKU" us e="required"/> <!-- añadimos los atributos pesoKg y enviarPor - -> <xsd:attribute name="pesoKg" type="xsd:decimal"/ > <xsd:attribute name="enviarPor"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="aire"/> <xsd:enumeration value="tierra"/> <xsd:enumeration value="cualquiera"/> </xsd:restriction> </xsd:simpleType> </xsd:attribute> </xsd:complexType></xsd:element>

Alternativamente, podemos crear un grupo de atributos con nombre que contenga todoslos atributos deseados de un elemento elemento , y referencie a este grupo por nombre en


22 de 57 16/01/2014 21:41

la declaración del elemento elemento :

Añadir Atributos Utilizando un Grupo de Atributos

<xsd:element name="elemento" minOccurs="0" maxOccur s="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="nombreProducto" type="xsd:str ing"/> <xsd:element name="cantidad"> <xsd:simpleType> <xsd:restriction base="xsd:positiveInteger"> <xsd:maxExclusive value="100"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="precioEEUU" type="xsd:decimal "/> <xsd:element ref="comentario" minOccurs="0"/> <xsd:element name="fechaEnvio" type="xsd:date" m inOccurs="0"/> </xsd:sequence>  <xsd:attributeGroup ref="EntregaElementos"/> </xsd:complexType></xsd:element><xsd:attributeGroup name="EntregaElementos"> <xsd:attribute name="numProducto" type="SKU" use= "required"/> <xsd:attribute name="pesoKg" type="xsd:decimal" /> <xsd:attribute name="enviarPor"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="are"/> <xsd:enumeration value="tierra"/> <xsd:enumeration value="cualquiera"/> </xsd:restriction> </xsd:simpleType> </xsd:attribute></xsd:attributeGroup>

Utilizando un grupo de atributos de este modo podemos aumentar la legibilidad de losesquemas, y facilitar la actualización de los esquemas porque un grupo de atributos puedeser definido y editado en un lugar y referenciado en múltiples definiciones y declaraciones.Estas características de los grupos de atributos los hacen similares a las entidadesparámetro en XML 1.0. Nota que un grupo de atributos puede contener otros grupos deatributos. Y también que las declaraciones de atributos y las de grupos de atributos debenaparecer al final de las declaraciones de tipos complejos.

2.9 Valores Nulos

Uno de los elementos de la hoja de pedido listada en po.xml , el cortaCesped , no tiene unelemento fechaEnvio . En el contexto de nuestro escenario, el autor del esquema puedehaber hecho dichas ausencias intencionadamente para indicar elemento s que aún no hansido enviados. Pero en general, la ausencia de un elemento no tiene un significadoparticular: puede indicar que la información es desconocida, o no es aplicable, o elelemento puede estar ausente por cualquier otra razón. A veces es deseable representarun elemento no enviado, información desconocida, o información no aplicable de maneraexplícita con un elemento, en vez de un elemento ausente. Por ejemplo, sería deseablerepresentar un valor "null" [nulo] que es enviado desde o hacia una base de datosrelacional con un elemento que esté presente. Tales casos pueden representarseutilizando el mecanismo nulo del Esquema XML que permite que un elemento puedaaparecer o no con un valor no-nulo.

El mecanismo nulo del Esquema XML funciona como una señal nula "fuera de banda". Esotras palabras, no hay un valor nulo que aparezca como contenido de un elemento, sinoque existe un atributo que indica que el contenido del elemento es nulo. Para ilustrar esto,modificamos la declaración del elemento fechaEnvio para que pueda aceptar valores


23 de 57 16/01/2014 21:41

nulos:

<xsd:element name="fechaEnvio" type="xsd:date" nill able="true"/>

Y para representar explícitamente que fechaEnvio tiene un valor nulo en el documentoinstancia, ponemos el valor del atributo nulo (el del espacio de nombres del Esquema XMLpara instancias) a true:

<fechaEnvio xsi:nil="true"></fechaEnvio>

El atributo nil [nulo] se define como parte del espacio de nombres para instancias delEsquema XML, http://www.w3.org/2001/XMLSchema-instance , y así puede aparecer en eldocumento instancia con un prefijo (como xsi: ) asociado con ese espacio de nombres.(Como con el prefijo xsd: , el prefijo xsi: es utilizado sólo por convención). Nótese que elmecanismo nulo se aplica sólo a valores de elementos, y no a valores de atributos. Unelemento con xsi:nil ="true" puede no tener contenido de elementos pero puede teneratributos.

�

3. Conceptos Avanzados I: Espacios de Nombres, Esquemas yCalificación

Un esquema puede ser visto como una colección (vocabulario) de definiciones de tipos ydeclaraciones de elementos cuyos nombres pertenecen a un determinado espacio denombres llamado espacio de nombres de destino. Los espacios de nombres de destinohacen posible la distinción entre definiciones y declaraciones de diferentes vocabularios.Por ejemplo, los espacios de nombres de destino facilitarían la declaración del elementoelement en el vocabulario del Esquema XML, y la declaración de element en un hipotéticovocabulario de lenguaje químico. El primero es parte de espacio de nombres de destinohttp://www.w3.org/2001/XMLSchema , y el segundo es parte de otro espacio de nombres dedestino.

Cuando queremos comprobar que un documento instancia conforma con uno o másesquemas (a través de un proceso llamado validación del esquema), necesitamosidentificar qué declaraciones de elementos y atributos y qué definiciones de tipos en losesquemas deberían utilizarse para según qué tipos en el documento instancia. Losespacios de nombres de destino juegan un papel importante en el proceso deidentificación. Examinaremos el papel del espacio de nombres en la próxima sección.

El autor de esquemas tiene diferentes opciones que afectan al modo en el que lasidentidades de elementos y atributos son representados en documentos instancia. Másespecíficamente, el autor puede decidir cuando la aparición de elementos y atributoslocales en una instancia debe estar o no calificada por un espacio de nombres, utilizando obien un prefijo explícito o bien implícitamente por defecto. La elección del autor deesquemas en cuanto a calificación de elementos y atributos locales tiene un número deimplicaciones en cuanto a las estructuras de los esquemas y de los documentos instancia,y examinaremos algunas de estas implicaciones en las secciones siguientes.

3.1 Espacios de Nombres y Locales Sin Calificar

En una versión nueva del esquema de la hoja de pedido, po1.xsd , declaramosexplícitamente un espacio de nombres, y especificamos que los elementos y atributosdefinidos localmente deben estar sin calificar. El espacio de nombres en po1.xsd eshttp://www.example.com/PO1 , como indica el valor del atributo targetNamespace [espacio


24 de 57 16/01/2014 21:41

de nombres de destino].

La calificación de los elementos y atributos locales puede ser especificada globalmente porun par de atributos, elementFormDefault [forma de elemento por defecto] yattributeFormDefault [forma de atributo por defecto] , en el elemento schema [esquema], opuede especificarse de forma separada para cada declaración local utilizando el atributoform [forma]. Cada uno de los valores de atributos de ese tipo puede tener el valorunqualified [sin calificar] o qualified [calificado], para indicar los casos en los que loselementos y atributos deben ser calificados o no.

En po1.xsd especificamos globalmente la calificación de elementos y atributos dando aelementFormDefault y attributeFormDefault el valor unqualified . Hablandoestrictamente, esto no es necesario porque son los valores por defecto de ambos atributos;los utilizamos aquí para resaltar el contraste entre este caso y otros casos que serándescritos más adelante.

Esquema de la Hoja de Pedido con Espacio de Nombres , po1.xsd

<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:po="http://www.example.com/PO1" targetNamespace="http://www.example.com/PO1 " elementFormDefault="unqualified" attributeFormDefault="unqualified"> <element name="hojaPedido" type="po:TipoHojaPedido "/> <element name="comentario" type="string"/> <complexType name="TipoHojaPedido"> <sequence> <element name="enviarA" type="po:direccionE EUU"/> <element name="facturarA" type="po:direccionE EUU"/> <element ref="po:comentario" minOccurs="0"/>  </sequence>  </complexType> <complexType name="direccionEEUU"> <sequence> <element name="nombre" type="string"/> <element name="calle" type="string"/>  </sequence> </complexType> </schema>

Para ver cómo se construye el espacio de nombres de este esquema, examinaremos una auna las definiciones de tipos y declaraciones de elementos. Comenzando por el principiodel esquema, primero definimos un tipo llamado direccionEEUU que contiene loselementos nombre , calle , etc. Una consecuencia de esta definición de tipo es que el tipodireccionEEUU está incluido en el espacio de nombres del esquema. A continuacióndefinimos un tipo denominado TipoHojaPedido que contiene los elementos enviarA ,facturarA , comentario , etc. TipoHojaPedido está también incluido en el espacio denombres del esquema. Nótese que las referencias de tipos en las declaraciones de los treselementos tienen prefijo, es decir, po:direccionEEUU,po:direccionEEUU y po:comentario , yel prefijo está asociado con el espacio de nombres http://www.example.com/PO1 . Este esel mismo espacio de nombres que el del esquema, y por tanto un procesador de esteesquema sabría que tiene que mirar dentro de este esquema para encontrar la definicióndel tipo direccionEEUU y la declaración del elemento comentario . También es posiblereferirse a tipos en otro esquema con un espacio de nombres diferente, y de esta formafacilitar la reutilización de las definiciones y declaraciones entre esquemas.

Al principio de po1.xsd , declaramos los elementos hojaPedido y comentario . Estánincluidos en el espacio de nombres del esquema. El tipo de elementos hojaPedido tieneprefijo por la misma razón que direccionEEUU lo tiene. Por contra, el tipo del elemento


25 de 57 16/01/2014 21:41

comentario , string , no tiene prefijo. El esquema po1.xsd contiene una declaración deespacio de nombre por defecto, y por eso los tipos sin prefijo como string y los elementossin prefijo como element y complexType están asociados al espacio de nombres por defectohttp://www.w3.org/2001/XMLSchema . De hecho, este es el espacio de nombres delEsquema en si mismo, y así un procesador de po1.xsd sabrá que tiene que mirar dentrodel esquema del Esquema XML -- conocido de otra forma como el "esquema para losesquemas" -- para encontrar la definición del tipo string y la declaración del elementoelement .

Examinemos cómo el espacio de nombres del esquema afecta a un documento instanciaque conforma con él:

Una Hoja de Pedido con Locales Sin Calificar, po1.x ml

<?xml version="1.0"?><apo:hojaPedido xmlns:apo="http://www.example.com/P O1" fechaPedido="1999-10-20"> <enviarA pais="EEUU"> <nombre>Alice Smith</nombre> <calle>123 Maple Street</calle>  </enviarA> <facturarA pais="EEUU"> <nombre>Robert Smith</nombre> <calle>8 Oak Avenue</calle>  </facturarA> <apo:comentario>¡Deprisa, mi césped parece una selva!</apo:comentario> </apo:hojaPedido>

El documento instancia declara un espacio de nombres, http://www.example.com/PO1 , y leasocia el prefijo apo: . Este prefijo es utilizado para calificar dos elementos en eldocumento, llamados hojaPedido y comentario . El espacio de nombres es el mismo que elespacio de nombres del esquema en po1.xsd , y por tanto un procesador del documentoinstancia sabrá buscar en ese esquema las declaraciones de hojaPedido y comentario . Dehecho, los espacios de nombres se denominan así por el sentido en el que existe unespacio de nombres para los elementos hojaPedido y comentario . Por tanto los espaciosde nombres indicados en el esquema controlan la validación de los correspondientesespacios de nombres de la instancia.

El prefijo apo: se aplica a los elementos globales hojaPedido y comentario . Más aún,elementFormDefault y attributeFormDefault requieren que el prefijo no sea aplicado aninguno de los elementos declarados localmente tales como enviarA , facturarA , nombre ycalle , y no es aplicado a ninguno de los atributos (todos fueron declarados localmente).La hojaPedido y el comentario son elementos globales porque están declarados en elcontexto del esquema como un todo en vez de ser declarados dentro del contexto de untipo particular. Por ejemplo, la declaración de hojaPedido aparece como un hijo delelemento schema en po1.xsd , mientras que la declaración de enviarA aparece como un hijodel elemento complexType que define el TipoHojaPedido .

Cuando no se requiere que los elementos y atributos locales estén calificados, un autor deinstancias puede necesitar más o menos conocimiento acerca de los detalles del esquemapara crear instancias válidas. Más específicamente, si el autor puede estar seguro de quesólo el elemento raíz (como hojaPedido ) es global, entonces es un caso simple en el quesólo hay que calificar el elemento raíz. En otro caso, el autor puede saber que todos loselementos están declarados globalmente, y por tanto todos los elementos de la instanciapueden tener prefijo, quizás aprovechando una declaración de espacio de nombres pordefecto. (Examinaremos esta aproximación en la Sección 3.3). Por otra parte, si no hay unpatrón uniforme de declaraciones locales y globales, el autor necesitará conocimientodetallado del esquema para asignar los prefijos a los elementos y atributos globales de


26 de 57 16/01/2014 21:41

forma correcta.

3.2 Locales Calificados

Los elementos y atributos pueden calificarse de forma independiente, aunqueempezaremos describiendo la calificación de elementos locales. Para especificar que todoslos elementos declarados localmente en un esquema deben estar calificados, ponemos elvalor de elementFormDefault a qualified :

Modificaciones a po1.xsd para Locales Calificados

<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:po="http://www.example.com/PO1" targetNamespace="http://www.example.com/PO1 " elementFormDefault="qualified" attributeFormDefault="unqualified"> <element name="hojaPedido" type="po:TipoHojaPedido "/> <element name="comentario" type="string"/> <complexType name="TipoHojaPedido">  </complexType> </schema>

Y en esta instancia que conforma con el esquema, calificamos todos los elementosexplícitamente:

Una Hoja de Pedido con Locales Calificados Explícit amente

<?xml version="1.0"?><apo:hojaPedido xmlns:apo="http://www.example.com/P O1" fechaPedido="1999-10-20"> <apo:enviarA pais="EEUU"> <apo:nombre>Alice Smith</apo:nombre> <apo:calle>123 Maple Street</apo:calle>  </apo:enviarA> <apo:facturarA country="US"> <apo:nombre>Robert Smith</apo:nombre> <apo:street>8 Oak Avenue</apo:alle>  </apo:facturarA> <apo:comentario>¡Deprisa, mi césped parece una selva!</apo:comentario> </apo:hojaPedido>

De forma alternativa, podemos reemplazar la calificación explícita de cada elemento poruna calificación implícita proporcionada por el espacio de nombres por defecto, como semuestra aquí en po2.xml :

Una Hoja de Pedido con Locales Calificados por Defe cto, po2.xml

<?xml version="1.0"?><hojaPedido xmlns="http://www.example.com/PO1" fechaPedido="1999-10-20"> <envarA pais="EEUU"> <nombre>Alice Smith</nombre> <calle>123 Maple Street</calle>  </shipTo> <facturarA pais="EEUU"> <nombre>Robert Smith</nombre> <calle>8 Oak Avenue</calle>  </facturarA> <comentario>¡Deprisa, mi césped parece una selv a!</comentario>


27 de 57 16/01/2014 21:41

</hojaPedido>

En po2.xml , todos los elementos de la instancia pertenecen al mismo espacio de nombres,y la declaración de espacio de nombres estipula un espacio de nombres por defecto quese aplica a todos los elementos de la instancia. Por tanto, no es necesario utilizar prefijo deforma explícita para ninguno de los elementos. Como otra ilustración del uso de elementoscalificados, los esquemas de la Sección 5 requieren todos elementos calificados.

La calificación de atributos es muy similar a la de elementos. Los atributos que deben sercalificados, ya sea porque han sido declarados globalmente o porque el atributoattributeFormDefault tiene un valor qualified , aparecen con prefijo en los documentosinstancia. Un ejemplo de un atributo calificado es el atributo xsi:nil que fue introducidoen la Sección 2.9. De hecho, los atributos que requieren ser calificados deben prefijarseexplícitamente porque la especificación XML-Namespaces [Espacios de Nombres XML] noproporciona un mecanismo para poner por defecto los espacio de nombres de losatributos. Los atributos que no requieren ser calificados aparecen en los documentosinstancia sin prefijos, que es el caso típico.

El mecanismo de calificación que hemos descrito hasta ahora ha controlado todas lasdeclaraciones de elementos y atributos dentro de un espacio de nombres particular.También es posible controlar la calificación en base a cada una de las declaraciones enparticular utilizando el atributo form . Por ejemplo, para requerir que el atributo declaradolocalmente clavePublica sea calificado en instancias, lo declaramos del siguiente modo:

Requirir la Calificación de un Único Atributo

<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:po="http://www.example.com/PO1" targetNamespace="http://www.example.com/PO1 " elementFormDefault="qualified" attributeFormDefault="unqualified">  <element name="seguro"> <complexType> <sequence>  </sequence> <attribute name="clavePublica" type="base64Binar y" form="qualified"/> </complexType> </element></schema>

Nótese que el valor del atributo form sustituye el valor del atributo attributeFormDefault

solamente para el atributo clavePublica . El atributo form también puede ser aplicado auna declaración de elemento de la misma forma. Un documento instancia que conformacon el esquema es:

Instancia con un Atributo Calificado

<?xml version="1.0"?><hojaPedido xmlns="http://www.example.com/PO1" xmlns:po="http://www.example.com/PO1 " fechaPedido="1999-10-20">  <seguro po:clavePublica="GpM7">  </seguro></hojaPedido>

3.3 Declaraciones Locales contra Globales


28 de 57 16/01/2014 21:41

Otro estilo de autoría, aplicable cuando los nombres de todos los elementos son únicosdentro de un espacio de nombres, es crear esquemas en los que todos los elementos songlobales. Esto tiene un efecto similar al uso de <!ELEMENT> en un DTD. En el ejemplosiguiente hemos modificado el po1.xsd original de forma que todos los elementos sondeclarados globalmente. Advierte que hemos omitido los atributos elementFormDefault yattributeFormDefault en este ejemplo para enfatizar que sus valores son irrelevantescuando sólo existen declaraciones globales de elementos y atributos.

Versión Modificada de po1.xsd utilizando sólo declaraciones globales deelementos

<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:po="http://www.example.com/PO1" targetNamespace="http://www.example.com/PO1 "> <element name="hojaPedido" type="po:TipoHojaPedido "/> <element name="enviarA" type="po:direccionEEUU" /> <element name="facturarA" type="po:direccionEEUU" /> <element name="comentario" type="string"/> <element name="nombre" type="string"/> <element name="calle" type="string"/> <complexType name="TipoHojaPedido"> <sequence> <element ref="po:enviarA"/> <element ref="po:facturarA"/> <element ref="po:comentario" minOccurs="0"/>  </sequence> </complexType> <complexType name="direccionEEUU"> <sequence> <element ref="po:nombre"/> <element ref="po:calle"/>  </sequence> </complexType> </schema>

Esta versión "global" de po1.xsd validará el documento instancia po2.xml , el cual, comodescribimos anteriormente, también valida contra el esquema la versión "calificada" depo1.xsd . En otras palabras, ambas formas de esquema, pueden validar el mismodocumento con espacio de nombres por defecto. Así, en un aspecto ambas formas delesquema son similares, aunque en otro importante aspecto ambas formas son muydiferentes. Específicamente, cuando todos los elementos son declarados globalmente, noes posible tener la ventaja de los nombres locales. Por ejemplo, sólo puedes declarar unelemento global llamado "titulo". Sin embargo, puedes declarar localmente un elementollamado "titulo" que sea de tipo string, y sea un subelemento de "libro". Dentro del mismoesquema (espacio de nombres) puedes declarar un segundo elemento también llamado"titulo" que sea una enumeración de los valores "Sr Sra Srta".

3.4 Espacios de Nombres Sin Declarar

En la Sección 2 explicamos la base del Esquema XML utilizando un esquema que nodeclaraba un espacio de nombres y un documento instancia que tampoco declaraba unespacio de nombres. Así que la pregunta surge de forma natural: ¿Cual es el espacio denombres en esos ejemplos y cómo se referencia?

En el esquema de la hoja de pedido, po.xsd , no declaramos un espacio de nombres parael esquema, ni tampoco declaramos un prefijo (como po: más arriba) asociado con elespacio de nombres del esquema con el que podríamos referenciar tipos y elementosdefinidos y declarados en el esquema. La consecuencia de no declarar un espacio denombres en un esquema es que las definiciones y declaraciones de ese esquema, talescomo direccionEEUU y hojaPedido , son referenciadas sin calificación del espacio de


29 de 57 16/01/2014 21:41

nombres. En otras palabras, no hay un prefijo explícito de un espacio de nombres ni hayningún espacio de nombres implícito aplicado a la referencia por defecto. Así, por ejemplo,el elemento hojaPedido es declarado utilizando como referencia el tipo TipoHojaPedido .Por contra, todos los elementos y tipos del Esquema XML utilizados en po.xsd estánexplícitamente calificados con el prefijo xsd: que está asociado con el espacio de nombresdel Esquema XML.

En los casos en los que el esquema es diseñado sin un espacio de nombres, serecomienda encarecidamente que todos los elementos y tipos del Esquema XML seancalificados explícitamente con un prefijo que esté asociado con el espacio de nombres delEsquema XML tal como xsd: (como en po.xsd ). El razonamiento para esta recomendaciónes que si los tipos y elementos del Esquema XML están asociados al espacio de nombresdel Esquema XML por defecto, es decir, sin prefijos, entonces las referencias a los tiposdel Esquema XML pueden no ser distinguibles de las referencias de tipos definidos por elusuario.

Las declaraciones de elementos de un esquema sin espacio de nombres determinadovalidan elementos sin calificar en el documento instancia. Esto es, validan elementos paralos que no se ha proporcionado calificación de espacio de nombres con prefijo explícito nipor defecto (xmlns: ). Así, para validar un documento tradicional XML 1.0 que no utilizaningún tipo de espacio de nombres, debes utilizar un esquema sin espacio de nombres.Por supuesto, hay muchos documentos XML 1.0 que no utilizan espacios de nombres, asíque habrá muchos documentos esquema escritos sin ningún espacio de nombres; debesasegurarte de dar a tu procesador un documento esquema que se corresponda con elvocabulario que deseas validar.

�

4. Conceptos Avanzados II: Hoja de Pedido Internacional

El esquema de la hoja de pedido descrito en el Capítulo 2 estaba contenido en un únicodocumento, y la mayoría de construcciones de los esquemas --tales como declaracionesde elementos y definiciones de tipos -- fueron construidas desde cero. En realidad, losautores de esquemas desearán componer esquemas a partir de construccioneslocalizadas en múltiples documentos, y crear tipos nuevos basados en tipos existentes. Enesta sección, examinamos los mecanismos que posibilitan tales composiciones ycreaciones.

4.1 Un Esquema en Múltiples Documentos

A medida que los esquemas se hacen más grandes, es a menudo deseable dividir sucontenido entre varios documentos esquema con propósitos tales como facilitar sumantenimiento, control de acceso, y legibilidad. Por estas razones, hemos sacado fuera depo.xsd las construcciones de esquema relativas a direcciones, y las hemos puesto en unfichero nuevo llamado address.xsd . El esquema de la hoja de pedido modificada se llamaipo.xsd :

Esquema de la Hoja de Pedido Internacional, ipo.xsd

<schema targetNamespace="http://www.example.com/IPO " xmlns="http://www.w3.org/2001/XMLSchema" xmlns:ipo="http://www.example.com/IPO"> <annotation> <documentation xml:lang="es"> Esquema de la Hoja de Pedido Internacional para Example.com Copyright 2000 Example.com. Todos los derechos r eservados. </documentation> </annotation>  <include


30 de 57 16/01/2014 21:41

schemaLocation="http://www.example.com/schemas/ad dress.xsd"/> <element name="hojaPedido" type="ipo:TipoHojaPedid o"/> <element name="comentario" type="string"/> <complexType name="TipoHojaPedido"> <sequence> <element name="enviarA" type="ipo:Direccio n"/> <element name="facturarA" type="ipo:Direccio n"/> <element ref="ipo:comentario" minOccurs="0"/> <element name="elementos" type="ipo:Elemento s"/> </sequence> <attribute name="fechaPedido" type="date"/> </complexType> <complexType name="Elementos"> <sequence> <element name="elemento" minOccurs="0" maxOccurs ="unbounded"> <complexType> <sequence> <element name="nombreProducto" type="string"/ > <element name="cantidad"> <simpleType> <restriction base="positiveInteger"> <maxExclusive value="100"/> </restriction> </simpleType> </element> <element name="precioEEUU" type="decimal"/ > <element ref="ipo:comentario" minOccurs="0"/> <element name="fechEnvio" type="date" min Occurs="0"/> </sequence> <attribute name="numProducto" type="ipo:SKU" u se="required"/> </complexType> </element> </sequence> </complexType> <simpleType name="SKU"> <restriction base="string"> <pattern value="\d{3}-[A-Z]{2}"/> </restriction> </simpleType></schema>

El archivo que contiene las construcciones es:

Direcciones para el Esquema de la Hoja de Pedido In ternacional, address.xsd

<schema targetNamespace="http://www.example.com/IPO " xmlns="http://www.w3.org/2001/XMLSchema" xmlns:ipo="http://www.example.com/IPO"> <annotation> <documentation xml:lang="es"> Direcciones para la Hoja de Pedido Internacional . Copyright 2000 Example.com. Todos los derechos r eservados. </documentation> </annotation> <complexType name="Direccion"> <sequence> <element name="nombre" type="string"/> <element name="calle" type="string"/> <element name="ciudad" type="string"/> </sequence> </complexType> <complexType name="direccionEEUU"> <complexContent> <extension base="ipo:Direccion"> <sequence> <element name="estado" type="ipo:estadoEEUU"/> <element name="zip" type="positiveInteger"/> </sequence> </extension> </complexContent> </complexType> <complexType name="direccionUK">


31 de 57 16/01/2014 21:41

<complexContent> <extension base="ipo:Direccion"> <sequence> <element name="codigoPostal" type="ipo:codigoP ostalUK"/> </sequence> <attribute name="codigoExportacion" type="posit iveInteger" fixed="1"/> </extension> </complexContent> </complexType>  <simpleType name="estadoEEUU"> <restriction base="string"> <enumeration value="AK"/> <enumeration value="AL"/> <enumeration value="AR"/>  </restriction> </simpleType> </schema>

Las diferentes construcciones para hojas de pedido y direcciones están ahora contenidasen dos archivos de esquemas distintos, ipo.xsd y address.xsd . Para incluir estasconstrucciones como parte del esquema de la hoja de pedido internacional, en otraspalabras, para incluirlas en el espacio de nombres de la hoja de pedido internacional,ipo.xsd contiene el elemento include :

<include schemaLocation="http://www.example.com/sch emas/address.xsd"/>

El efecto de este elemento include es incluir las definiciones y declaraciones contenidasen address.xsd , y hacer que estén disponibles como parte del espacio de nombres delesquema de la hoja de pedido internacional. La única advertencia de importancia a teneren cuenta al utilizar include es que el espacio de nombres de los componentes incluidosdebe ser el mismo que el espacio de nombres del esquema incluido, en este casohttp://www.example.com/IPO . Incluir definiciones y declaraciones mediante el mecanismoque proporciona include , añade estos componentes realmente al espacio de nombresexistente. En la Sección 4.5, describiremos un mecanismo similar que hace posible que sepuedan modificar ciertos componentes una vez incluidos.

En nuestro ejemplo, hemos mostrado sólo un documento incluido y un documento que loincluye. En la práctica es posible incluir más de un documento utilizando múltipleselementos include , y los documentos pueden incluir a otros que a su vez incluyen otrosdocumentos. Sin embargo, anidar documentos de esta manera es sólo legal si todas laspartes incluidas en el esquema están incluidas en el mismo espacio de nombres.

Los documentos instancia que conforman con el esquema cuyas definiciones se extiendenpor múltiples documentos esquema, sólo necesitan referenciar al esquema de 'mayor nivel'y al espacio de nombres común, y es responsabilidad del procesador el unir todas lasdefiniciones incluidos en los distintos documentos. En nuestro ejemplo de antes, eldocumento instancia ipo.xml (ver Sección 4.3) sólo hace referencia al espacio de nombrescomún, http://www.example.com/IPO , y (por implicación) al archivo de esquemahttp://www.example.com/schemas/ipo.xsd . El procesador es el responsable de obtener elarchivo de esquema address.xsd .

En la Sección 5.4 describiremos cómo los esquemas pueden utilizarse para validarcontenido de más de un espacio de nombres.

4.2 Derivación de Tipos por Extensión

Para crear nuestras construcciones de direcciones, comenzamos creando un tipo complejollamado Direccion del modo usual (ver address.xsd ). El tipo Direccion contiene los


32 de 57 16/01/2014 21:41

elementos básicos de una dirección: un nombre, una calle y una ciudad. (Tal definición nofuncionará para todos los países, pero sirve para el propósito de nuestro ejemplo). Desdeeste punto de inicio derivamos dos nuevos tipos complejos que contienen todos loselementos del tipo original y elementos adicionales que son específicos para lasdirecciones de EEUU y las de UK. La técnica que utilizamos aquí para derivar nuevos tipos(complejos) de direcciones extendiendo un tipo existente es la misma técnica queutilizamos en la Sección 2.5.1, excepto porque nuestro tipo base aquí es un tipo complejomientras que nuestro tipo base en la sección mencionada era un tipo simple.

Definimos dos tipos complejos nuevos, direccionEEUU y direccionUK , utilizando elelemento complexType . Además indicamos que los modelos de contenido de los nuevostipos son complejos, es decir, contienen elementos, e indicamos que estamos extendiendoel tipo base Direccion por el valor del atributo base en el elemento extension .

Cuando un elemento complejo se deriva por extensión, su modelo de contenido efectivo esel modelo de contenido del tipo base añadiéndole el modelo de contenido especificado enla derivación del tipo. Es más, los dos modelos de contenido son tratados como dos hijosde un grupo secuencial. En el caso de direccionUK , el modelo de contenido dedireccionUK es el modelo de contenido de Direccion añadiéndole las declaraciones paraun elemento codigoPostal y un atributo codigoExportacion . Esto es como definir ladireccionUK desde cero como sigue:

Ejemplo

<complexType name="direccionUK"> <sequence>  <element name="nombre" type="string"/> <element name="calle" type="string"/> <element name="ciudad" type="string"/>  <element name="codigoPostal" type="ipo:codigoPos talUK"/> </sequence>  <attribute name="codigoExportacion" type="positiv eInteger" fixed="1"/> </complexType>

4.3 Uso de Tipos Derivados en Documentos Instancia

En nuestro caso de ejemplo, las hojas de pedido son generadas en respuesta a pedidosde clientes lo que puede incluir direcciones de envío y facturación en diferentes países. Lahoja de pedido internacional de abajo, ipo.xml , ilustra un caso así en el que los productosson enviados a UK y la factura es enviada a una dirección de EEUU. Claramente es mejorsi el esquema para hojas de pedido internacionales no tiene que especificar cada posiblecombinación de direcciones internacionales para facturación y envío, e incluso aún mejor sipodemos añadir nuevos tipos complejos de direcciones internacionales sin más que crearnuevas derivaciones de Direccion .

El Esquema XML nos permite definir los elementos facturarA y enviarA como tiposDireccion (ver ipo.xsd ) pero utilizar instancias de direcciones internacionales en lugar deinstancias de Direccion . En otras palabras, un documento instancia cuyo contenidoconforme con el tipo direccionUK será válido si el contenido aparece dentro del documentoen un lugar en el que se espera la aparición de una Direccion (asumiendo que elcontenido de la direccionUK es válido en si mismo). Para hacer que esta característica delesquema funcione, y para identificar exactamente qué tipo derivado se pretende utilizar, eltipo derivado debe ser identificado en el documento instancia. El tipo se identificautilizando el atributo xsi:type que es parte del espacio de nombres de la instancia delEsquema XML. En el ejemplo, el uso de ipo.xml de los tipos derivados direccionUK ydireccionEEUU se identifica a través de los valores asignados a los atributos xsi:type .


33 de 57 16/01/2014 21:41

Una Hoja de Pedido Internacional, ipo.xml

<?xml version="1.0"?><ipo:hojaPedido xmlns:xsi="http://www.w3.org/2001/XMLSchema-insta nce" xmlns:ipo="http://www.example.com/IPO" fechaPedido="1999-12-01"> <enviarA codigoExportacion="1" xsi:type="ipo:di reccionUK"> <nombre>Helen Zoe</nombre> <calle>47 Eden Street</calle> <ciudad>Cambridge</ciudad> <codigoPostal>CB1 1JR</codigoPostal> </enviarA> <facturarA xsi:type="ipo:direccionEEUU"> <nombre>Robert Smith</nombre> <calle>8 Oak Avenue</calle> <ciudad>Old Town</estado> <estado>PA</state> <zip>95819</zip> </facturarA> <elementos> <elemento numProducto="833-AA"> <nombreProducto>Collar de Lapis</nombre Producto> <cantidad>1</cantidad> <precioEEUU>99.95</precioEEUU> <ipo:comentario>¡Lo quiero para las vac aciones!</ipo:comentario> <fechaEnvio>1999-12-05</fechaEnvio> </elemento> </elementos></ipo:hojaPedido>

En la Sección 4.8 describiremos como prevenir el que los tipos derivados sean utilizadosen este tipo de sustituciones.

4.4 Derivación de Tipos Complejos por Restricción

En adición a la derivación de tipos complejos nuevos por extensión de modelos decontenido, es posible derivar tipos nuevos por restricción de modelos de contenido de tiposexistentes. La restricción de tipos complejos es conceptualmente igual que la restricción detipos simples, excepto en que la restricción de tipos complejos implica a las declaracionesde un tipo en vez de el rango de valores aceptable que utiliza un tipo simple. Un tipocomplejo derivado por restricción es muy parecido a su tipo base, excepto en que susdeclaraciones están más limitadas que las declaraciones correspondientes de su tipo base.De hecho, los valores representados por el tipo nuevo son un subconjunto de los valoresrepresentados por el tipo base (como en el caso de restricción de tipos simples). En otraspalabras, una aplicación preparada para los valores del tipo base no se verá sorprendidapor los valores del tipo derivado.

Por ejemplo, supongamos que queremos actualizar nuestra definición de la lista deelementos en una hoja de pedido internacional para que deba contener al menos unelemento en el pedido, el esquema mostrado en ipo.xsd permite que un elementoelementos aparezca sin ningún elemento hijo elemento . Para crear nuestro tipo nuevoElementosConfirmados , definimos el tipo del modo habitual, indicando que es derivado porrestricción del tipo base Elementos y proporciona un valor nuevo (más restrictivo) para elnúmero mínimo de ocurrencias del elemento elemento . Nótese que los tipos derivados porrestricción deben todos los componentes de la definición del tipo base que deben serincluidos en el tipo derivado:

Derivación de ElementosConfirmados por Restricción a partir de Elementos

<complexType name="ElementosConfirmados"> <complexContent> <restriction base="ipo:Elementos"> <sequence>


34 de 57 16/01/2014 21:41

<element name="elemento" minOccurs="1" maxOccur s="unbounded">  <complexType> <sequence> <element name="nombreProducto" type="string" /> <element name="cantidad"> <simpleType> <restriction base="positiveInteger"> <maxExclusive value="100"/> </restriction> </simpleType> </element> <element name="precioEEUU" type="decimal" /> <element ref="ipo:comentario" minOccurs="0"/ > <element name="fechaEnvio" type="date" mi nOccurs="0"/> </sequence> <attribute name="numProducto" type="ipo:SKU" use="required"/> </complexType> </element> </sequence> </restriction> </complexContent></complexType>

Este cambio, requiriendo uno o más elementos hijo en vez de permitir cero o máselementos hijo, restringe el número de elementos hijo permitidos de un mínimo de 0 a unmínimo de 1. Nótese que todos los elementos de tipo ElementosConfirmados serán tambiénaceptables como elementos de tipo Elemento .

Para ilustrar aún más esta restricción, la Tabla 3 muestra varios ejemplos de cómo puedenrestringirse las declaraciones de elementos y atributos en las definiciones de tipos (la tablamuestra sintaxis de elementos aunque los tres primeros ejemplos son restricciones deatributos igualmente válidas).

Tabla 3. Ejemplos de Restricción

Base�� Restricción Notas

� default="1"establece un valor por defecto donde antes no habíaninguno establecido

� fixed="100"establece un valor fijo donde antes no había ningunoestablecido

� type="string"especifica un tipo donde antes no había ningunoestablecido

(minOccurs ,maxOccurs )

(minOccurs ,maxOccurs ) ��

(0, 1) (0, 0)exclusión de un componente opcional, esto tambiénpuede conseguirse omitiendo la declaración delcomponente de la definición del tipo restringido

(0, unbounded) (0, 0) (0, 37) �

(1, 9)(1, 8) (2, 9) (4, 7)

(3, 3) �

(1, unbounded)(1, 12) (3,

unbounded) (6,6)

�

(1, 1) - no se pueden restringir ni minOccurs ni maxOccurs

4.5 Redefinición de Tipos y Grupos


35 de 57 16/01/2014 21:41

En la Sección 4.1 describimos cómo incluir definiciones y declaraciones obtenidas dearchivos de esquema externos que tienen el mismo espacio de nombres. El mecanismoinclude facilita el uso de componentes de esquema creados externamente "tal cual", estoes, sin ninguna modificación. Acabamos de describir cómo derivar tipos por restricción ypor extensión, y el mecanismo redefine que describimos aquí posibilita la redefinición detipos complejos y simples, de grupos, y de grupos de atributos que se obtienen dearchivos de esquema externos. Al igual que el mecanismo include , redefine requiere quelos componentes externos estén en el mismo espacio de nombres que el esquema que losva a redefinir, aunque los componentes externos que no tienen espacio de nombresalguno, también pueden ser redefinidos. En éste último caso, los componentes externosredefinidos se hacen parte del espacio de nombres del esquema que los redefine.

Para ilustrar el mecanismo redefine , lo utilizamos en lugar del mecanismo include en elesquema de la Hoja de Pedido Internacional, ipo.xsd , y lo utilizamos para modificar ladefinición del tipo complejo Direccion contenida en address.xsd :

Utilización de redefine en la Hoja de Pedido Interna cional

<schema targetNamespace="http://www.example.com/IPO " xmlns="http://www.w3.org/2001/XMLSchema" xmlns:ipo="http://www.example.com/IPO">  <complexType name="Direccion"> <complexContent> <extension base="ipo:Direccion"> <sequence> <element name="pais" type="string"/> </sequence> </extension> </complexContent> </complexType> </redefine> </schema>

El elemento redefine actúa de forma muy parecida al elemento include ya que incluyetodas las declaraciones y definiciones del archivo address.xsd . La definición de tipocomplejo de Direccion utiliza la sintaxis de extensión familiar para añadir un elemento pais

a la definición de Direccion . De todas formas, el tipo base es también Direccion . Fueradel elemento redefine , cualquier intento de definir un tipo complejo con el mismo nombre(y el mismo espacio de nombres) como el tipo base del que está siendo derivado, causa unerror. Pero en este caso, no hay tal error, y la definición extendida de Direccion seconvierte en la única definición de Direccion .

Ahora que Direccion ha sido redefinido, la extensión se aplica a todos los componentesdel esquema que hacen uso de Direccion . Por ejemplo, address.xsd contiene definicionesde tipos de direcciones internacionales que se derivan de Direccion . Estas derivacionesreflejan el tipo address.xsd redefinido, como se muestra en el siguiente fragmento:

Fragmento de ipo.xml utilizando Dirección Redefinida

.... <enviarA exportCode="1" xsi:type="ipo:direccionUK" > <nombre>Helen Zoe</nombre> <calle>47 Eden Street</calle> <ciudad>Cambridge</ciudad>  <pais>United Kingdom</pais>  <codigoPostal>CB1 1JR</codigoPostal> </enviarA>


36 de 57 16/01/2014 21:41

....

Nuestro ejemplo ha sido cuidadosamente construido de manera que el tipo redefinidoDireccion no entra en conflicto en modo alguno con los tipos que son derivados de ladefinición original de Direccion . Pero nótese que sería muy fácil crear un conflicto. Porejemplo, si las derivaciones del tipo dirección internacional hubiesen extendido Direccion

añadiendo un elemento pais , entonces la redefinición de Direccion estaría añadiendo unelemento del mismo nombre al modelo de contenido de Direccion . Es ilegal tener doselementos del mismo nombre (y en el mismo espacio de nombres) pero diferentes tipos enun modelo de contenido, y así el intento de redefinir Direccion causaría un error. Engeneral, redefine no protege de tales errores, y debería ser utilizado con cuidado.

4.6 Grupos de Sustitución

El Esquema XML proporciona un mecanismo, llamado grupos de sustitución, que permiteque los elementos sean sustituidos por otros elementos. De forma más específica, loselementos pueden ser asignados a un grupo especial de elementos que son sustuituiblespor un elemento particular llamado el elemento cabecera. (Nótese que el elementocabecera debe ser declarado como un elemento global). Para ilustrarlo, declaramos doselementos llamados comentarioCliente y comentarioEnvio y los asignamos a un grupo desustitución cuyo elemento cabecera es comentario y así comentarioCliente ycomentarioEnvio pueden ser utilizados en cualquier lugar en el que pudiésemos utilizarcomentario . Los elementos de los grupos de sustitución deben tener el mismo tipo que elelemento cabecera, o pueden tener un tipo que haya sido derivado del tipo del elementocabecera. Para declarar estos dos nuevos elementos, y para hacerlos sustituibles por elelemento comentario , utilizamos la siguiente sintaxis:

Declaración de Elementos Sustituibles por comentari o

<element name="comentarioEnvio" type="string" substitutionGroup="ipo:comentario"/><element name="comentarioCliente" type="string" substitutionGroup="ipo:comentario"/>

Cuando estas declaraciones son añadidas al esquema de la hoja de pedido internacional,comentarioCliente y comentarioEnvio pueden ser sustituidos por comentario en eldocumento instancia, por ejemplo:

Fragmento de ipo.xml con Elementos Sustituidos

.... <elementos> <elemento numProducto="833-AA"> <nombreProducto>Collar de Lapis</nombreProduct o> <cantidad>1</cantidad> <precioEEUU>99.95</precioEEUU> <ipo:comentarioEnvio> Utilizar recubrimiento de oro si es posible </ipo:comentarioEnvio> <ipo:comentarioCliente> ¡Lo quiero para las vacaciones! </ipo:comentarioCliente> <fechaEnvio>1999-12-05</fechaEnvio> </elemento> </elementos>....

Nótese que cuando un documento instancia contiene sustituciones de elementos cuyostipos son derivados de los de sus elementos cabecera, no es necesario identificar los tiposderivados utilizando la construcción xsi:type que describimos en la Sección 4.3.


37 de 57 16/01/2014 21:41

La existencia de un grupo de sustitución no requiere que ninguno de los elementos de laclase sea utilizado, ni excluye el uso de un elemento cabecera. Simplemente proporcionaun mecanismo para permitir los elementos ser usados de forma intercambiable.

4.7 Elementos y Tipos Abstractos

El Esquema XML proporciona un mecanismo para forzar la sustitución de un elemento otipo particular. Cuando un elemento o tipo se declara como "abstracto", no puede serutilizado en un documento instancia. Cuando un elemento se declara como abstracto, unmiembro de su grupo de sustitución debe aparecer en el documento instancia. Cuando ladefinición de tipo correspondiente a un elemento es declarada como abstracta, todas lasinstancias de ese elemento deben utilizar xsi:type para indicar cualquier tipo derivado queno sea abstracto.

En el ejemplo de grupo de sustitución descrito en la Sección 4.6, sería útil deshabilitar eluso del elemento comentario para que las instancias deban hacer uso de los elementoscomentarioCliente y comentarioEnvio . Para declarar el elemento comentario comoabstracto, modificamos su declaración original en el esquema de la orden de pedidointernacional, ipo.xsd , como sigue:

<element name="comentario" type="string" abstract=" true"/>

Con comentario declarado como abstracto, ahora las instancias de las hojas de pedidointernacional son sólo válidas si contienen elementos comentarioCliente ycomentarioEnvio .

Declarar un elemento como abstracto requiere el uso de un grupo de sustitución. Declararun tipo como abstracto requiere simplemente el uso de un tipo derivado de él (eidentificado por el atributo xsi:type ) en el documento instancia. Considérese la siguientedefinición de esquema:

Esquema para Vehículos

<schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://cars.example.com/s chema" xmlns:destino="http://cars.example.com/sch ema"> <complexType name="Vehiculo" abstract="true"/> <complexType name="Coche"> <complexContent> <extension base="destino:Vehiculo"/> </complexContent> </complexType> <complexType name="Avion"> <complexContent> <extension base="destino:Vehiculo"/> </complexContent> </complexType> <element name="transporte" type="target:Vehiculo"/ ></schema>

El elemento transporte no es abstracto, por tanto puede aparecer en documentosinstancia. De todas formas, como su definición de tipo es abstracta, nunca podrá apareceren un documento instancia si el atributo xsi:type que se refiere a un tipo derivado. Esosignifica que lo siguiente no es esquema-válido:

<transporte xmlns="http://cars.example.com/schema"/ >

porque el tipo del elemento transporte es abstracto. Sin embargo, lo siguiente sí esesquema-válido:


38 de 57 16/01/2014 21:41

<transporte xmlns="http://cars.example.com/schema" xmlns:xsi="http://www.w3.org/2001/XMLSc hema-instance" xsi:type="Car"/>

porque utiliza un tipo no abstracto que es sustituible por Vehiculo .

4.8 Control de la Creación y Uso de Tipos Derivados

Hasta ahora, hemos podido derivar tipos nuevos y utilizarlos en documentos instancia sinningún tipo de impedimento. En realidad, los autores de esquemas querrán controlar enocasiones las derivaciones de tipos particulares, y el uso de tipos derivados en instancias.

El Esquema XML proporciona un par de mecanismos que controlan la derivación de tipos.Uno de esos mecanismos permite al autor de esquemas especificar que para un tipocomplejo particular, los tipos nuevos no puedan derivar de él, bien por (a) restricción o bienpor (b) extensión o (c) de ninguna manera. Para ilustrarlo supongamos que no queremospermitir que se pueda derivar del tipo Direccion por restricción porque pretendemos quesólo sea utilizado como tipo base para tipos extendidos como direccionEEUU ydireccionUK . Para prevenir tales derivaciones, modificaremos un poco la definición originalde direccionEEUU como sigue:

Prevención de Derivaciones por Restricción de Direc cion

<complexType name="Direccion" final="restriction"> <sequence> <element name="nombre" type="string"/> <element name="calle" type="string"/> <element name="ciudad" type="string"/> </sequence></complexType>

El valor restriction del atributo final previene las derivaciones por restricción. Laprevención de las derivaciones del todo, o por extensión, se indica con los valores #all yextension respectivamente. Más aún, existe un atributo opcional finalDefault en elelemento schema cuyo valor puede ser uno de los valores permitidos para el atributo final .El efecto de especificar un atributo finalDefault es equivalente al de especificar unatributo final para cada definición de tipo y declaración de elemento en el esquema.

Otro tipo para el control de la derivación de tipos, controla las propiedades que pueden seraplicadas en la derivación de un tipo simple nuevo. Cuando un tipo simple es definido, elatributo fixed puede ser aplicado a cualquiera de sus propiedades para prevenir que laderivación de ese tipo modifique el valor de esas propiedades fijadas. Por ejemplo,podemos definir un tipo simple codigoPostal como:

Prevención de Cambios en Propiedades de Tipos Simpl es

<simpleType name="codigoPostal"> <restriction base="string"> <length value="7" fixed="true"/> </restriction></simpleType>

Una vez que este tipo simple ha sido definido, podemos derivar un tipo nuevo de códigopostal en el que aplicamos una propiedad no fijada en la definición, por ejemplo:

Derivación Legal de codigoPostal

<simpleType name="codigoPostalUK"> <restriction base="ipo:codigoPostal"> <pattern value="[A-Z]{2}\d\s\d[A-Z]{2}"/>


39 de 57 16/01/2014 21:41

</restriction></simpleType>

Sin embargo, no podemos derivar un código postal nuevo en el que re-apliquemoscualquier propiedad que fuese fijada en la definición del tipo base:

Derivación Ilegal de codigoPostal

<simpleType name="codigoPostalUK"> <restriction base="ipo:codigoPostal"> <pattern value="[A-Z]{2}\d\d[A-Z]{2}"/>  <length value="6" fixed="true"/> </restriction></simpleType>

Además de los mecanismos que controlan las derivaciones de tipo, el Esquema XMLproporciona un mecanismo que controla qué derivaciones y grupos de sustitución puedenser usados en documentos instancia. En la Sección 4.3, describimos cómo los tiposderivados direccionEEUU y direccionUK , podrían ser utilizados por los elementos enviarA yfacturarA en documentos instancia. Estos tipos derivados pueden reemplazar el modelode contenido proporcionado por el tipo Direccion porque se derivan del tipo Direccion . Sinembargo, el reemplazo por tipos derivados puede controlarse utilizando el atributo block

[bloqueo] en una definición de tipo. Por ejemplo, si queremos bloquear cualquierderivación por restricción para que no sea usada en el lugar de Direccion (quizás por lamisma razón por la que definimos Direccion con final ="restriction" ), podemosmodificar la definición original de final ="restriction" como sigue:

Prevención de Derivaciones por Restricción de Direc ción en una Instancia

<complexType name="Direccion" block="restriction"> <sequence> <element name="nombre" type="string"/> <element name="calle" type="string"/> <element name="ciudad" type="string"/> </sequence></complexType>

El valor restriction del atributo block previene que haya derivaciones por restricción quereemplacen a Direccion en una instancia. Sin embargo, no prevendría el quedireccionEEUU y direccionUK reemplazaran a Direccion porque fueron derivadas porextensión. La prevención de todo tipo de derivaciones, o de derivaciones por extensión, seindica con los valores #all y extension respectivamente. Como con final , existe unatributo opcional blockDefault en el elemento schema cuyo valor puede ser uno de losvalores permitidos para el atributo block . El efecto de especifcar el atributo blockDefault

es equivalente a especificar un atributo block para cada definición de tipo y declaración deelemento del esquema.

�

5. Conceptos Avanzados III: El Informe Trimestral

La aplicación de pedidos y facturación puede generar informes ad-hoc que resumen quécantidad de cada tipo de producto ha sido facturada para cada región. Un ejemplo de esetipo de informe, uno que cubre el último trimestre de 1999, se muestra en 4Q99.xml .

Nótese que en esta sección se utilizan elementos calificados en el esquema, y , dentro delo posible, espacios de nombres por defecto en las instancias.


40 de 57 16/01/2014 21:41

Informe Trimestral, 4Q99.xml

<informePedidos xmlns="http://www.example.com/Report" periodo="P3M" finPeriodo="1999-12-31"> <regiones> <zip codigo="95819"> <producto numero="872-AA" cantidad="1"/> <producto numero="926-AA" cantidad="1"/> <producto numero="833-AA" cantidad="1"/> <producto numero="455-BX" cantidad="1"/> </zip> <zip codigo="63143"> <producto numero="455-BX" cantidad="4"/> </zip> </regiones> <productos> <producto numero="872-AA">Cortacésped</part> <producto numero="926-AA">Monitor de Bebés</part> <producto numero="833-AA">Collar de Lapis</part> <producto numero="455-BX">Estanterías Robustas</p art> </productos></informePedidos>

El informe lista, por número y cantidad, los productos facturados a diferentes códigos decalles, y proporciona una descripción de cada producto mencionado. Al resumir lo datos defacturación, la intención del informe es clara y los datos no son ambiguos porque existe uncierto número de restricciones de uso. Por ejemplo, cada código de calle aparece sólo unavez (restricción de unicidad). De manera similar, la descripción de cada producto facturadoaparece una sola vez aunque los productos pueden ser facturados a varios códigospostales (restricción referencial), véase por ejemplo el producto número 455-BX . En lassecciones siguientes, veremos como especificar estas constantes utilizando el EsquemaXML.

El Esquema del Informe, report.xsd

<schema targetNamespace="http://www.example.com/Rep ort" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:r="http://www.example.com/Report" xmlns:xipo="http://www.example.com/IPO" elementFormDefault="qualified">  <import namespace="http://www.example.com/IPO"/> <annotation> <documentation xml:lang="es"> Esquema para Informes para Example.com Copyright 2000 Example.com. Todos los derechos r eservados. </documentation> </annotation> <element name="informePedidos"> <complexType> <sequence> <element name="regiones" type="r:TipoRegion"> <keyref name="cualquiera2" refer="r:pNumClave" > <selector xpath="r:zip/r:producto"/> <field xpath="@numero"/> </keyref> </element> <element name="productos" type="r:TipoProducto" /> </sequence> <attribute name="periodo" type="duration"/> <attribute name="finPeriodo" type="date"/> </complexType> <unique name="cualquiera1"> <selector xpath="r:regiones/r:zip"/> <field xpath="@codigo"/> </unique> <key name="pNumClave"> <selector xpath="r:productos/r:producto"/>


41 de 57 16/01/2014 21:41

<field xpath="@numero"/> </key> </element> <complexType name="TipoRegion"> <sequence> <element name="zip" maxOccurs="unbounded"> <complexType> <sequence> <element name="producto" maxOccurs="unbounded "> <complexType> <complexContent> <restriction base="anyType"> <attribute name="numero" type="xipo:SKU "/> <attribute name="cantidad" type="positive Integer"/> </restriction> </complexContent> </complexType> </element> </sequence> <attribute name="codigo" type="positiveInteger "/> </complexType> </element> </sequence> </complexType> <complexType name="TipoProducto"> <sequence> <element name="producto" maxOccurs="unbounded"> <complexType> <simpleContent> <extension base="string"> <attribute name="numero" type="xipo:SKU"/> </extension> </simpleContent> </complexType> </element> </sequence> </complexType></schema>

5.1 Especificar Unicidad

El Esquema XML nos facilita el indicar que cualquier valor de un atributo o elemento seaúnico en un cierto ámbito. Para indicar que un valor de un "campo" de un atributo oelemento debe ser único, utilizamos el elemento unique [único] primero para "seleccionar"un conjunto de elementos, y después para identificar el "campo" del atributo o elementorelativo a cada elemento seleccionado y que tiene que ser único dentro del ámbito delconjunto de elementos seleccionados. En el caso de nuestro esquema para informes,report.xsd , el atributo xpath del elemento selector contiene una expresión XPath,regiones/zip , que selecciona una lista de todos los elementos zip en una instancia deinforme. Del mismo modo, el atributo xpath del elemento selector contiene una segundaexpresión XPath, @codigo , que indica que los valores de los atributos codigo , de esoselementos deben ser únicos. Nótese que las expresiones XPath limitan el ámbito de lo quedebe ser único. El informe debe contener otro atributo codigo , pero sus valores no tienenporqué ser únicos porque cae fuera del ámbito definido por las expresiones XPath.También hay que resaltar que las expresiones XPath que se pueden utilizar en el atributoxpath están limitadas a un subconjunto del lenguaje XPath completo definido en XML PathLanguage 1.0.

También podemos indicar combinaciones de campos que deben ser únicas. Para ilustrarlo,supongamos que podemos relajar la restricción de que los códigos zip puedan ser listadossólo una vez, aunque aún deseamos mantener la restricción de que un productocualquiera sea listado una sola vez dentro de un código dado. Podemos lograr talrestricción especificando que la combinación del código zip y del número de producto seaúnica. Del documento del informe, 4Q99.xml , los valores combinados de codigo y numero


42 de 57 16/01/2014 21:41

serían: {95819 872-AA }, {95819 926-AA }, {95819 833-AA }, {95819 455-BX }, y {63143 455-BX }.Claramente, estas combinaciones no distinguen entre combinaciones de codigo y numero

zip derivadas de una o varias listas para un código zip particular, pero las combinacionesrepresentarían de forma no ambigua un producto listado más de una vez para un únicozip. En otras palabras, un procesador de esquemas podría detectar violaciones de larestricción de unicidad.

Para definir combinaciones de valores, simplemente añadimos elementos field [campo]para identificar los valores involucrados. así, para añadir el número de producto a nuestradefinición existente, añadimos un nuevo elemento field cuyo atributo xpath que vale,producto/@numero , identifica el atributo numero de los elementos producto que son hijos delos elementos zip identificados por regiones/zip :

Un Valor Único Compuesto

<unique name="cualquiera1"> <selector xpath="r:regiones/r:zip"/> <field xpath="@codigo"/> <field xpath="r:producto/@numero"/> </unique>

5.2 Definición de Claves y sus Referencias

En el informe trimestral de 1999 la descripción de cada producto sólo aparece una vez.Podemos imponer esta restricción utilizando unique , sin embargo, también queremosasegurar que cualquier elemento cantidad-producto listado bajo un código zip tiene unadescripción de producto correspondiente. Imponemos la restricción utilizando loselementos key [clave] y keyref [referencia clave]. El esquema de informes report.xsd ,muestra que las construcciones key y keyref son aplicadas utilizando casi la mismasintaxis que unique . Los elementos clave se aplican al valor del atributo numero de loselementos producto que son hijos del elemento productos . Esta declaración de numero

como clave significa que su valor debe ser único y no puede ser igualado a nil (es decir, noes anulable), y el nombre asociado con la clave, pNumClave , hace que ésta seareferenciable desde cualquier otro sitio.

Para asegurar que los elementos cantidad-producto tienen sus correspondientesdescripciones de producto, decimos que el atributo numero ( <field>@numero</field> ) deesos elementos (<selector>zip/producto</selector> ) debe referenciar la clave pNumClave .Esta declaración de numero como una keyref no significa que su valor deba ser único, perosignifica que debe existir una pNumClave con el mismo valor.

Como te habrás imaginado por analogía con unique , es posible definir combinaciones devalores key y keyref . utilizando este mecanismo, podemos ir más allá del simplerequerimiento de que los números de los productos sean iguales, y definir unacombinación de valores que debe ser igual. Tales valores pueden ser de combinaciones demúltiples tipos de valores combinaciones de valores (string , integer , date , etc.),comprobando que el orden y tipo de la referencia del elemento field es la misma en lasdefiniciones de key y keyref .

5.3 Restricciones del Esquema XML frente a Atributos ID de XML 1.0

XML 1.0 proporciona un mecanismo de unicidad utilizando el atributo ID que es asociadocon los atributos IDREF y IDREFS. Este mecanismo también está presente en el EsquemaXML a través de los tipos simples ID , IDREF, y IDREFS que pueden ser utilizados paradeclarar atributos del estilo de los de XML 1.0. El Esquema XML también introducemecanismo nuevos que son más flexibles y potentes. Por ejemplo, los mecanismos delEsquema XML pueden ser aplicados a cualquier contenido de elemento o atributo, sin


43 de 57 16/01/2014 21:41

importar su tipo. Por contra, ID es un tipo de atributo y por tanto no puede ser aplicado aatributos, elementos o a su contenido. Más aún, el Esquema facilita la posibilidad deespecificar el ámbito dentro del cual se aplica la unicidad mientras que el ámbito de un IDes fijado a todo el documento. Finalmente, el Esquema facilita la posibilidad de crear key so una keyref a partir de combinaciones del contenido de elementos y atributos mientrasque el ID no tiene esta posibilidad.

5.4 Importación de Tipos

El esquema de los informes, report.xsd , hace uso del tipo simple xipo:SKU que estádefinido en otro esquema, y en otro espacio de nombres. Recordemos que hemos utilizadoinclude así que el esquema de ipo.xsd podría hacer uso de las definiciones ydeclaraciones de address.xsd . No podemos usar include aquí porque sólo puede incluirdeclaraciones y definiciones de un esquema con el mismo espacio de nombres que elesquema en el que lo queremos incluir. Por tanto, el elemento include no identifica unespacio de nombres (aunque requiere un schemaLocation ). El mecanismo de importaciónque describimos en esta sección es un mecanismo importante que permite quecomponentes de esquemas procedentes de diferentes partes puedan ser utilizadosconjuntamente, y por tanto posibilita la validación de esquemas con contenido definido enmúltiples espacios de nombres.

Para importar el tipo SKU y utilizarlo en el esquema de los informes, identificamos elesquema en el que SKU está definido, y asociamos ese espacio de nombres con un prefijopara usarlo en el esquema de los informes. Concretamente, utilizamos el elemento import

para identificar el espacio de nombres de SKU, http://www.example.com/IPO , y asociamosel espacio de nombres con el prefijo xipo utilizando una declaración de tipo estándar. Eltipo simple SKU, definido en el espacio de nombres http://www.example.com/IPO , entoncespuede ser referenciado como xipo:SKU en cualquiera de las definiciones y declaracionesdel esquema.

En nuestro ejemplo, importamos un tipo simple de un espacio de nombres externo, y loutilizamos para declarar atributos. De hecho el Esquema XML permite importar múltiplescomponentes de esquema, de múltiples espacios de nombres, y pueden ser referenciadostanto por definiciones como por declaraciones. Por ejemplo, en report.xsd , podríamosademás reutilizar el elemento comentario declarado en ipo.xsd referenciando eseelemento en una declaración:

<element ref="xipo:comentario"/>

Nótese de todas formas, que no podemos reutilizar el elemento enviarA de po.xsd , y quelo siguiente no es legal porque sólo pueden importarse componentes globales de unesquema:

<element ref="xipo:enviarA"/>

En ipo.xsd , comentario es declarado como un elemento global, en otras palabras esdeclarado como un elemento del schema. Por contra, enviarA es declarado localmente, enotras palabras es un elemento declarado dentro de una definición de tipo complejo,específicamente el tipo TipoHojaPedido .

Los tipos complejos también pueden importarse, y pueden ser utilizados como los tiposbase para derivar tipos nuevos. Sólo se pueden importar tipos complejos con nombre; lostipos locales o definidos de forma anónima no pueden ser importados. Supongamos quequeremos incluir en nuestros informes el nombre de un analista, junto con su informaciónde contacto. Podemos reutilizar el tipo complejo (definido globalmente) direccionEEUU deaddress.xsd , y extenderlo para definir un tipo nuevo llamado Analista añadiendo los


44 de 57 16/01/2014 21:41

elementos nuevos telefono y email :

Definición de Analista por Extensión de direccionEE UU

<complexType name="Analista"> <complexContent> <extension base="xipo:direccionEEUU"> <sequence> <element name="telefono" type="string"/> <element name="email" type="string"/> </sequence> </extension> </complexContent></complexType>

Para utilizar este tipo nuevo declaramos un elemento llamado analista como parte de ladeclaración del elemento informePedidos (no se muestran las declaraciones) en elesquema de los informes. Entonces, la siguiente instancia de documento conformaría conel esquema de informes modificado:

Documento Instancia que Conforma con el Esquema de Informes con el TipoAnalista

<informePedidos xmlns="http://www.example.com/Report" periodo="P3M" finPeriodo="1999-12-31">  <analista> <nombre>Wendy Uhro</nombre> <calle>10 Corporate Towers</calle> <ciudad>San Jose</ciudad> <estado>CA</estado> <zip>95113</zip> <telefono>408-271-3366</telefono> <email>[email protected]</email> </analista></informePedidos>

Cuando los componentes del esquema son importados de múltiples espacios de nombres,cada espacio de nombres debe identificarse con un import separado. Los elementosimport por si mismos deben aparecer como el primero de los hijos del elemento schema. Esmás, cada espacio de nombres debe estar asociado con un prefijo, utilizar una declaraciónde espacio de nombres de tipo estándar, y que el prefijo sea utilizado para calificarreferencias realizadas a los componentes pertenecientes a ese espacio de nombres.Finalmente, los elementos import contienen opcionalmente un atributo schemaLocation

para ayudar a localizar los recursos asociados con los espacios de nombres. Discutiremosel atributo schemaLocation con más detalle en una sección posterior.

5.4.1 Bibliotecas de Tipos

A medida que el uso de los esquemas XML se vaya extendiendo, los autores de esquemasquerrán ir creando tipos simples y complejos que puedan ser compartidos y utilizadoscomo ladrillos para la construcción de nuevos esquemas. Los Esquemas XML yaproporcionan tipos que juegan este papel, en particular, los tipos descritos en el Apéndicede Tipos Simples y en una biblioteca de tipos preliminar.

Los autores de esquemas querrán indudablemente crear sus propias bibliotecas de tipospara representar monedas, unidades de medida, direcciones de negocios, y demás. Cadabiblioteca debería de consistir de un esquema que contenga una o más definiciones, porejemplo, un esquema que contiene un tipo de moneda:


45 de 57 16/01/2014 21:41

Ejemplo de Tipo de Moneda en una Biblioteca de Tipo s

<schema targetNamespace="http://www.example.com/Cur rency" xmlns:c="http://www.example.com/Currency" xmlns="http://www.w3.org/2001/XMLSchema"> <annotation> <documentation xml:lang="es"> Definición del tipo Moneda basado en la ISO 4217 </documentation> </annotation> <complexType name="Moneda"> <simpleContent> <extension base="decimal"> <attribute name="nombre"> <simpleType> <restriction base="string"> <enumeration value="AED"> <annotation> <documentation xml:lang="es"> Emiratos Árabes Unidos: Dirham (1 Dirham = 100 Fils) </documentation> </annotation> </enumeration> <enumeration value="AFA"> <annotation> <documentation xml:lang="es"> Afganistán: Afghani (1 Afghani = 100 Pul s) </documentation> </annotation> </enumeration> <enumeration value="ALL"> <annotation> <documentation xml:lang="es"> Albania, Lek (1 Lek = 100 Qindarka) </documentation> </annotation> </enumeration>  </restriction> </simpleType> </attribute> </extension> </simpleContent> </complexType></schema>

Un ejemplo de aparición de un elemento de este tipo en una instancia:

<convertirDe nombre="AFA">199.37</convertirDe>

Una vez que hemos definido el tipo moneda, podemos hacer que esté disponible para serusado por otros esquemas mediante el mecanismo import recientemente descrito.

5.5 Elemento [Elemento Cualquiera], Atributo Any [Atributo Cualquiera]

En secciones anteriores hemos visto varios mecanismos para extender el modelo decontenido de tipos complejos. Por ejemplo, un modelo de contenido mixto puede contenerdatos de caracteres además de elementos, y por ejemplo, un modelo de contenido puedecontener elementos cuyos tipos son importados de espacios de nombres externos. Sinembargo, estos mecanismos proporcionan un control muy amplio y muy pequeñorespectivamente. El propósito de esta sección es describir un mecanismo flexible quepermita que los modelos de contenido sean extendidos por cualquier elemento o atributoque pertenezca a un espacio de nombres especificado.

Para ilustrarlo, consideremos una versión del informe trimestral, 4Q99html.xml , en la quehemos incluido una representación HTML de los datos XML de productos. El contenido


46 de 57 16/01/2014 21:41

HTML aparece como el contenido de el elemento ejemploHTML , y el espacio de nombrespor defecto es cambiado en el elemento HTML más externo (table ) por lo que todos loselementos pertenecen al espacio de nombres HTML, http://www.w3.org/1999/xhtml :

Informe Trimestral con HTML, 4Q99html.xml

<informePedidos xmlns="http://www.example.com/Report" periodo="P3M" finPeriodo="1999-12-31"> <regiones>  </regiones> <productos>  </productos> <ejemploHTML> <table xmlns="http://www.w3.org/1999/xhtml" border="0" width="100%"> <tr> <th align="left">Código Zip</th> <th align="left">Número de Producto</th> <th align="left">Cantidad</th> </tr> <tr><td>95819</td><td> </td><td> </td></tr> <tr><td> </td><td>872-AA</td><td>1</td></tr> <tr><td> </td><td>926-AA</td><td>1</td></tr> <tr><td> </td><td>833-AA</td><td>1</td></tr> <tr><td> </td><td>455-BX</td><td>1</td></tr> <tr><td>63143</td><td> </td><td> </td></tr> <tr><td> </td><td>455-BX</td><td>4</td></tr> </table> </ejemploHTML></informePedidos>

Para permitir la aparición de HTML en el documento instancia hemos modificado elesquema del informe declarando un elemento nuevo ejemploHTML cuyo contenido esdefinido por el elemento any . En general, un elemento any especifica que cualquier XMLbien formado es permisible en el modelo de contenido de un tipo. En el ejemplo,requerimos que el XML pertenezca al espacio de nombres http://www.w3.org/1999/xhtml ,en otras palabras, debe ser HTML. El ejemplo también requiere que haya al menos unelemento presente para este espacio de nombres, como se indica en los valores deminOccurs y maxOccurs :

Modificación al informePedido para permitir HTML en la Instancia

<element name="informePedido"> <complexType> <sequence> <element name="regiones" type="r:TipoRegiones"/ > <element name="productos" type="r:TipoProductos" /> <element name="ejemploHTML"> <complexType> <sequence> <any namespace="http://www.w3.org/1999/xhtml" minOccurs="1" maxOccurs="unbounded" processContents="skip"/> </sequence> </complexType> </element> </sequence> <attribute name="periodo" type="duration"/> <attribute name="finPeriodo" type="date"/> </complexType></element>

La modificación permite que aparezca algo de contenido XML bien formado peteneciente alespacio de nombres http://www.w3.org/1999/xhtml dentro del elemento ejemploHTML . Por


47 de 57 16/01/2014 21:41

consiguiente 4Q99html.xml está permitido porque hay un elemento, el cual (y sus hijos)está bien formado, el elemento aparece dentro del elemento apropiado (ejemploHTML ), y eldocumento instancia asegura que el elemento y su contenido pertenecen al espacio denombres requerido. Sin embargo, el HTML podría no ser realmente válido porque no haynada en 4Q99html.xml por si mismo que pueda proporcionar esa garantía. Si se requieretal garantía, el valor del atributo processContents [proceso de contenidos] debería ser iguala strict [estricto] (el valor por defecto). En este caso, el procesador de XML está obligadoa obtener el esquema asociado con el espacio de nombres requerido, y validar el HTMLque aparece dentro del elemento ejemploHTML .

En otro ejemplo, definimos un tipo texto que es similar al tipo text [texto] definido en labiblioteca de tipos preliminar del Esquema XML (ver también la Sección 5.4.1), y esapropiado para texto internacionalizado legible por humanos. El tipo text permite unamezcla sin restricciones de caracteres y elementos de cualquier espacio de nombres, porejemplo anotaciones Ruby con un atributo xml:lang opcional. El valor lax del atributoprocessContents instruye al procesador XML para que valide el contenido de elemento enbase a lo que puede-hacer: validará elementos y atributos para los que puede obtenerinformación del esquema, pero no señalará errores para los que no puede obtenerla.

Tipo Text [Tipo Texto ]

<xsd:complexType name="texto"> <xsd:complexContent mixed="true"> <xsd:restriction base="xsd:anyType"> <xsd:sequence> <xsd:any processContents="lax" minOccurs="0" ma xOccurs="unbounded"/> </xsd:sequence> <xsd:attribute ref="xml:lang"/> </xsd:restriction> </xsd:complexContent></xsd:complexType>

Los espacios de nombres pueden ser utilizados para permitir y prohibir contenido deelementos de varias formas dependiendo del valor del atributo namespace , como semuestra en la Tabla 4:

Tabla 4. Atributo Namespace en Any

Valor del AtributoNamespace

Contenido de Elemento Permitido

##anyCualquier XML bien formado de cualquier espacio denombres (por defecto)

##localCualquier XML bien formado y sin calificar, es decir, nodeclarado como perteneciente a un espacio de nombres

##otherCualquier XML bien formado que no es del espacio denombres del tipo que está siendo definido

"http://www.w3.org/1999/xhtml##targetNamespace"

Cualquier XML bien formado perteneciente a cualquierespacio de nombres perteneciente a la lista (elementosseparados por espacios en blanco); ##targetNamespace esun atajo para el espacio de nombres del elemento que estásiendo definido

Además del elemento any que facilita la inclusión de elementos de acuerdo con losespacios de nombres respectivos, existe un elemento correspondiente llamadoanyAttribute [cualquierAtributo] que posibilita la aparición de atributos en elementos. Porejemplo, podemos permitir que cualquier atributo HTML aparezca como parte del elementoejemploHTML añadiendo anyAttribute a su declaración:


48 de 57 16/01/2014 21:41

Modificación a la Declaración de ejemploHTML para P ermitir Atributos HTML

<element name="ejemploHTML"> <complexType> <sequence> <any namespace="http://www.w3.org/1999/xhtml" minOccurs="1" maxOccurs="unbounded" processContents="skip"/> </sequence> <anyAttribute namespace="http://www.w3.org/1999/x html"/> </complexType></element>

Esta declaración permite que un atributo HTML, pongamos href , aparezca en el elementoejemploHTML . Por ejemplo:

Un atributo HTML en el elemento ejemploHTML

.... <ejemploHTML xmlns:h="http://www.w3.org/1999/xhtm l" h:href="http://www.example.com/repor ts/4Q99.html">  </ejemploHTML>....

El atributo namespace en un elemento anyAttribute puede tener un valor igual a cualquierade los valores listados en la Tabla 4 para el elemento any , y anyAttribute puede serespecificado con un atributo processContents . A diferencia de un elemento any ,anyAttribute no puede restringir el número de atributos que puede aparecer en unelemento.

5.6 schemaLocation [ubicación del esquema]

El Esquema XML utiliza los atributos schemaLocation y xsi:schemaLocation en trescircunstancias:

1. En un documento instancia, el atributo xsi:schemaLocation proporciona indicaciones delautor para el procesador en cuanto a la localización de documentos de esquema. El autorgarantiza que estos documentos de esquemas son relevantes para comprobar la validezdel contenido del documento, en base a cada uno de los espacios de nombres. Porejemplo, podemos indicar la localización del esquema de Informes a un procesador delInforme Trimestral:

Utilización de schemaLocation en el Informe Trimestr al, 4Q99html.xml

<informePedidos xmlns="http://www.example.com/Report" xmlns:xsi="http://www.w3.org/2001/XMLSchema-insta nce" xsi:schemaLocation="http://www.example.com/Report http://www.example.com/Report.xsd" periodo="P3M" finPeriodo="1999-12-31"> </informePedidos>

El atributo schemaLocation contiene parejas de valores. El primer miembro de cada par esel espacio de nombres para el que el segundo miembro es la indicación de dónde seencuentra el documento del esquema adecuado. La presencia de estas indicaciones noobliga al procesador a utilizar los esquemas citados, y el procesador es libre de utilizarotros esquemas obtenidos por cualquier otro medio apropiado, o de no usar ningúnesquema.


49 de 57 16/01/2014 21:41

No es obligatorio que un esquema tenga un espacio de nombres (ver Sección 3.4) y poreso tenemos un atributo noNamespaceSchemaLocation que es utilizado para proporcionarindicaciones para la localización de esquemas en los documentos que no tienen unespacio de nombres asociado.

2. En un esquema, el elemento include tiene un atributo schemaLocation obligatorio, ycontiene una referencia URI que debe identificar a un esquema. El efecto es componer unesquema final efectivo mediante la mezcla de las declaraciones y definiciones de losesquemas que se incluyen y del esquema incluye a éstos. Por ejemplo, en la Sección 4,las definiciones de los tipos direccion , direccionEEUU , direccionUK , estadoEEUU (junto conlas declaraciones de sus elementos y atributos locales) de address.xsd fueron añadidas alas declaraciones de los elementos de hojaPedido y comentario , y las definiciones de tipode TipoHojaPedido , Elementos y SKU (junto con las declaraciones de sus elementos yatributos locales) de ipo.xsd para crear un único esquema.

3. También en un esquema, el elemento import tiene unos atributos namespace yschemaLocation . Si aparecen, el atributo schemaLocation es entendido en un modoparalelo a la interpretación de xsi:schemaLocation en (1). Específicamente, proporcionauna indicación del autor a un procesador en cuanto a la localización del esquema que elautor garantiza que proporciona los componentes necesarios para el espacio de nombresidentificado por el atributo namespace . Para importar componentes que no están en ningúnespacio de nombres, el elemento import se usa sin un atributo namespace (y con o sin unatributo schemaLocation ). Las referencias a elementos importados de esta manera sehacen sin calificar.

Recuerda que el schemaLocation es sólo una indicación y que algunos procesadores yaplicaciones tendrán razones para no utilizarlo. Por ejemplo, un editor HTML puede tenerun esquema HTML predefinido.

5.7 Concordancia

Un documento instancia puede ser procesado contra un esquema para verificar que lasreglas especificadas en el esquema son cumplidas por la instancia. Típicamente, talproceso hace dos cosas, (1) comprueba la corcondancia con las reglas, un procesollamado validación de esquema, y (2) añade información suplementaria que no estáinmediatamente presente en la instancia, como tipos y valores por defecto, llamadoscontribuciones al conjunto de información.

El autor de un documento instancia, tal como una hoja de pedido concreta, puedeespecificar, en la misma instancia, que conforme (concuerde) con las reglas de unesquema particular. El autor hace esto utilizando el atributo schemaLocation discutidoanteriormente. Pero sin importar si un atributo schemaLocation está o no presente, unaaplicación es libre de procesar el documento contra cualquier esquema. Por ejemplo, unaaplicación de pedidos pude tener la política de utilizar siempre el mismo esquemadeterminado de hoja de pedido, a pesar de cualquier valor de schemaLocation .

La comprobación de concordancia puede ser pensada como un proceso en tres pasos,primero se comprueba que el elemento raíz del documento instancia tiene los contenidosadecuados, entonces se comprueba que cada subelemento conforma con su descripciónen el esquema, y así hasta que el documento completo se verifica. Los procesadoresdeben informar de qué tipo de comprobaciones han llevado a cabo.

Para comprobar la concordancia de un elemento, el procesador primero localiza ladeclaración del elemento targetNamespace en el esquema, y entonces comprueba que elatributo en el esquema coincide con el de URI de espacio de nombres actual del elemento.Alternativamente, se puede determinar que el esquema no tiene un atributotargetNamespace y que el elemento de la instancia no está calificado.

Suponiendo que los espacios de nombres concuerden, el procesador entonces examina el


50 de 57 16/01/2014 21:41

tipo del elemento, ya sea el dado por la declaración en el esquema o el del atributoxsi:type en la instancia. Si se da este último caso, el tipo de la instancia debe ser de untipo que pueda ser sustituido por el dado en el esquema, lo que es permitido se controlamediante el atributo block en la declaración del elemento. En ese mismo momento, seaplican los valores por defecto y otras contribuciones al conjunto de la información.

A continuación el procesador comprueba los contenidos y los atributos propios delelemento, comparando estos valores con los permitidos por el tipo del elemento. Porejemplo, consideremos un elemento enviarA tal como el de la Sección 2.1, el procesadorcomprueba lo que es permitido para una direccion , porque ese es el tipo del elementoenviarA .

Si el elemento tiene un tipo simple, el procesador verifica que el elemento no tieneatributos ni contiene elementos, y que su contenido de tipos carácter coincide con lasreglas para el tipo simple. Esto, en ocasiones, obliga a la comprobación de la secuencia decaracteres contra expresiones regulares o enumeraciones, y a veces a comprobar que lasecuencia de caracteres representa un valor dentro de un rango permitido.

Si el elemento tiene tipo complejo, entonces el procesador comprueba que los atributosrequeridos están presentes y que sus valores concuerdan con los requerimientos de sustipos simples. También comprueba que todos los subelementos requeridos esténpresentes, y que la secuencia de elementos (y de cualquier texto mezclado) coincide conel modelo de contenido declarado para el tipo complejo. En cuanto a los subelementos, losesquemas pueden o bien requerir coincidencia exacta de nombres, permitir sustitución porun elemento equivalente o permitir sustitución por cualquier elemento permitido por unapartícula 'any'.

A no ser que el esquema lo indique de manera contraria (como puede hacerlo mediantepartículas 'any'), la comprobación de concordancia procede entonces con el siguiente nivelmás profundo inspeccionando cada elemento uno a uno, repitiendo el proceso descritoarriba.

�

A Reconocimientos

Mucha gente ha contribuido con sus ideas, material y comentarios que han mejorado estedocumento. En particular, el editor quiere reconocer las contribuciones de David Beech,Paul Biron, Don Box, Allen Brown, David Cleary, Dan Connolly, Roger Costello, MartinDürst, Martin Gudgin, Dave Hollander, Joe Kesselman, John McCarthy, Andrew Layman,Eve Maler, Ashok Malhotra, Noah Mendelsohn, Michael Sperberg-McQueen, HenryThompson, Misha Wolf, y Priscilla Walmsley por validar los ejemplos.

B Tipos Simples y sus Propiedades

Los valores legales para cada tipo simple pueden ser restringidos por la aplicación de unao más propiedades. Las Tablas B1.a y B1.b listan todos los tipos simples y todas laspropiedades aplicables a cada uno de los tipos, que vienen predefinidas en el EsquemaXML. Los nombres de los tipos simples y sus propiedades están enlazados a las tablascon sus correspondientes descripciones en Esquema XML Parte 2: Tipos de Datos

Tabla B1.a. Tipos Simples y Propiedades Aplicables

Tipos Simples Propiedades

�� length[longitud]

minLength[longitud

maxLength[longitud

pattern[patrón]

enumeration[enumeración]

whiteSpace[espacios


51 de 57 16/01/2014 21:41

mínima] máxima] en blanco]

string y y y y y y

normalizedString y y y y y y

token y y y y y y

byte � � � y y y

unsignedByte � � � y y y

base64Binary y y y y y y�hexBinary y y y y y y

integer � � � y y y

positiveInteger � � � y y y

negativeInteger � � � y y y

nonNegativeInteger � � � y y y

nonPositiveInteger � � � y y y

int � � � y y y

unsignedInt � � � y y y

long � � � y y y

unsignedLong � � � y y y

short � � � y y y

unsignedShort � � � y y y

decimal � � � y y y

float � � � y y y

double � � � y y y

boolean � � � y � y

time � � � y y y

dateTime � � � y y y

duration � � � y y y

date � � � y y y

gMonth � � � y y y

gYear � � � y y y

gYearMonth � � � y y y

gDay � � � y y y

gMonthDay � � � y y y

Name y y y y y y

QName y y y y y y

NCName y y y y y y

anyURI y y y y y y

language y y y y y y

ID y y y y y y

IDREF y y y y y y

IDREFS y y y � y y

ENTITY y y y y y y


52 de 57 16/01/2014 21:41

ENTITIES y y y � y y

NOTATION y y y y y y

NMTOKEN y y y y y y

NMTOKENS y y y � y y

Las propiedades listadas en la Tabla B1.b se aplican sólo a tipos simples ordenados. Notodos los simples están ordenados por lo que B1.b no lista todos los tipos simples.

Tabla B1.b. Tipos Simples y Propiedades Aplicables

Tipos Simples Propiedades

��

maxInclusive[máximoinclusive]

maxExclusive[máximo

exclusive]

minInclusive[mínimo

inclusive]

minExclusive[mínimo

exclusive]

totalDigits[dígitostotales]

fractionDigits[dígitos defracción]

byte y y y y y y

unsignedByte y y y y y y

integer y y y y y y

positiveInteger y y y y y y

negativeInteger y y y y y y

nonNegativeInteger y y y y y y

nonPositiveInteger y y y y y y

int y y y y y y

unsignedInt y y y y y y

long y y y y y y

unsignedLong y y y y y y

short y y y y y y

unsignedShort y y y y y y

decimal y y y y y y

float y y y y � �double y y y y � �time y y y y � �dateTime y y y y � �duration y y y y � �date y y y y � �gMonth y y y y � �gYear y y y y � �gYearMonth y y y y � �gDay y y y y � �gMonthDay y y y y � �

C Uso de Entities [Uso de Entidades]

XML 1.0 proporciona varios tipos de entidades que son fragmentos de contenidos a los quese le da un nombre y que pueden ser utilizados en DTD's (entidades parámetro) y en


53 de 57 16/01/2014 21:41

documentos instancia. En la Sección 2.7, explicamos cómo los grupos con nombremimetizan a las entidades parámetro. En esta sección mostramos cómo las entidadespueden ser declaradas en los esquemas.

Supongamos que queremos declarar y usar una entidad en un documento, y que esedocumento también esté restringido por un esquema. Por ejemplo:

Declaración y referenciación de una entidad en un d ocumento instancia.

<?xml version="1.0" ?><!DOCTYPE hojaPedido [<!ENTITY eacute "é">]><hojaPedido xmlns="http://www.example.com/PO1" fechaPedido="1999-10-20>  <ciudad>Montréal</ciudad> </hojaPedido>

Aquí, declaramos una entidad llamada eacute como parte de un subconjunto (DTD)interno, y referenciamos esta entidad en el contenido del elemento ciudad . Nótese quecuando esta instancia es procesada, la entidad será dereferenciada antes de que tengalugar la validación del esquema. En otras palabras, un procesador del esquemadeterminará la validad del elemento ciudad utilizando Montréal como el valor del elemento.

Podemos lograr un efecto similar pero no idéntico declarando un elemento en unesquema, y utilizando un contenido apropiado para el mismo:

<xsd:element name="eacute" type="xsd:token" fixed=" é"/>

Y este elemento puede ser utilizado en un documento instancia:

Utilización de un elemento en lugar de una entidad e n un documento instancia.

<?xml version="1.0" ?><hojaPedido xmlns="http://www.example.com/PO1" xmlns:c="http://www.example.com/char acterElements" fechaPedido="1999-10-20>  <ciudad>Montr<c:eacute/>al</ciudad> </hojaPedido>

En este caso, un procesador del esquema procesará dos elementos, un elemento ciudad ,y un elemento eacute para los contenidos de los que el procesador obtendrá el caráctersimple é. El elemento extra complicará la comparación de cadenas; las dos formas dadasdel nombre "Montréal" en los dos ejemplos anteriores no coincidirán utilizando técnicasnormales de comparación de cadenas.

D Expresiones Regulares

La propiedad pattern del Esquema XML utiliza un lenguaje de expresiones regulares quesoporta Unicode. Está totalmente descrito en Esquema Parte 2. El lenguaje es similar allenguaje de expresiones regulares utilizado en el Lenguaje de Programación Perl, aunquelas expresiones son comparadas con representaciones totalmente léxicas en vez de conrepresentaciones enfocadas léxicamente al usuario como línea y párrafo. Por esta razón, ellenguaje de expresiones no contiene los metacaracteres ^ y $, aunque ^ se utiliza paraexpresar excepción. p.e. [^0-9]x.


54 de 57 16/01/2014 21:41

Tabla D1. Ejemplos de Expresiones Regulares

Expresión Coincidencia(s)

Capitulo \d Capitulo 0, Capitulo 1, Capitulo 2 ....

Capitulo\s\dCapitulo seguido de un único espacio en blanco (espacio, tabulador,nueva línea, etc.), seguido de un único dígito

Capitulo\s\wCapitulo seguido de un único espacio en blanco (espacio, tabulador,nueva línea, etc.), seguido de un carácter (Letra o Dígito XML 1.0t)

Espanñola Española

\p{Lu}cualquier letra mayúscula, el valor de \p{} (p.e. "Lu") es definido porUnicode

\p{IsGreek}cualquier carácter Griego, la construcción 'Is' puede ser aplicada acualquier nombre elemento nombre (p.e. "Greek") según definido porUnicode

\P{IsGreek}cualquier carácter No Griego, la construcción 'Is' puede ser aplicada acualquier nombre elemento nombre (p.e. "Greek") según definido porUnicode

a*x x, ax, aax, aaax ....

a?x ax, x

a+x ax, aax, aaax ....

(a|b)+xax, bx, aax, abx, bax, bbx, aaax, aabx, abax, abbx, baax, babx, bbax,bbbx, aaaax ....

[abcde]x ax, bx, cx, dx, ex

[a-e]x ax, bx, cx, dx, ex

[-ae]x -x, ax, ex

[ae-]x ax, ex, -x

[^0-9]x cualquier carácter no-dígito seguido del carácter x

\Dx cualquier carácter no-dígito seguido del carácter x

.x cualquier carácter seguido del carácter x

.*abc.* 1x2abc, abc1x2, z3456abchooray ....

ab{2}x abbx

ab{2,4}x abbx, abbbx, abbbbx

ab{2,}x abbx, abbbx, abbbbx ....

(ab){2}x ababx

E Índice

Elementos del Esquema XML . Cada nombre de elemento está enlazado a su descripciónen las partes de Estructuras o Tipos de Datos de la especificación del Esquema XML. Losnombres de elementos están seguidos de uno o más enlaces a ejemplos (identificados pornúmero de sección) en este documento de Fundamentos.

all : 2.7annotation : 2.6any : 5.5anyAttribute : 5.5appInfo : 2.6attribute : 2.2attributeGroup : 2.8choice : 2.7


55 de 57 16/01/2014 21:41

complexContent : 2.5.3complexType : 2.2documentation : 2.6element : 2.2enumeration : 2.3extension : 2.5.1, 4.2field : 5.1group : 2.7import : 5.4include : 4.1key : 5.2keyref : 5.2length : 2.3.1list : 2.3.1maxInclusive : 2.3maxLength : 2.3.1minInclusive : 2.3minLength : 2.3.1pattern : 2.3redefine : 4.5restriction : 2.3, 4.4schema : 2.1selector : 5.1sequence : 2.7simpleContent : 2.5.1simpleType : 2.3union : 2.3.2unique : 5.1

�

Atributos del Esquema XML . Cada nombre de atributo está seguido de uno o más paresde referencias. Cada par de referencias consiste de enlace a un ejemplo en estosFundamentos, además de un enlace a su descripción formal en las partes de Estructuraso Tipos de Datos de la especificación del Esquema XML.

abstract : declaración del elemento [ Estructuras], definición del tipo complejo [Estructuras]attributeFormDefault : elemento schema [ Estructuras]base : definición del tipo simple [ Tipos de Datos], definición del tipo complejo [Estructuras]block : definición del tipo complejo [ Estructuras],blockDefault : elemento schema [ Estructuras]default : declaración de atributo [ Estructuras],default : declaración del elemento [ Estructuras],elementFormDefault : elemento schema [ Estructuras]final : definición del tipo complejo [ Estructuras]finalDefault : elemento schema [ Estructuras]fixed : declaración de atributo [ Estructuras],fixed : declaración del elemento [ Estructuras]fixed : definición del tipo simple [Tipos de Datos]form : declaración del elemento [ Estructuras], declaración de atributo [ Estructuras]itemType : definición de tipo lista [ Tipos de Datos]memberTypes : definición de tipo unión [ Tipos de Datos]maxOccurs : declaración del elemento [ Estructuras]minOccurs : declaración del elemento [ Estructuras]mixed : definición del tipo complejo [ Estructuras]name: declaración del elemento [ Estructuras], declaración de atributo [ Estructuras],


56 de 57 16/01/2014 21:41

definición del tipo complejo [ Estructuras], definición del tipo simple [ Tipos de Datos]namespace : elemento any [ Estructuras], include element [ Estructuras]noNamespaceSchemaLocation : elemento instance [Estructuras]xsi:nil :element instance [Estructuras]nillable : declaración del elemento [ Estructuras]processContents : elemento any [ Estructuras], anyAttribute element [ Estructuras]ref : declaración del elemento [ Estructuras]schemaLocation : especificación de include [ Estructuras], especificación de redefine [Estructuras], especificación de import [ Estructuras]xsi:schemaLocation : atributo instancia [ Estructuras]substitutionGroup : declaración del elemento [ Estructuras]targetNamespace : elemento schema [ Estructuras]type : declaración del elemento [ Estructuras], declaración de atributo [ Estructuras]xsi:type : instance element [Estructuras]use : declaración de atributo [ Estructuras]xpath : selector & field elements [ Estructuras]

Los tipos simples del Esquema XML están descritos en la Tabla 2.

�


57 de 57 16/01/2014 21:41

esquema xml parte 0_ fundamentos

Documents