Esquema XML Parte 0: Fundamentos

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 o elemento 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 elemento relativo a cada elemento seleccionado y que tiene que ser único dentro del ámbito del conjunto 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 de informe. Del mismo modo, el atributo xpath del elemento selector contiene una segunda expresión XPath, @codigo, que indica que los valores de los atributos codigo, de esos elementos deben ser únicos. Nótese que las expresiones XPath limitan el ámbito de lo que debe ser único. El informe debe contener otro atributo codigo, pero sus valores no tienen porqué 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 atributo xpath están limitadas a un subconjunto del lenguaje XPath completo definido en XML Path Language 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 listados sólo una vez, aunque aún deseamos mantener la restricción de que un producto cualquiera sea listado una sola vez dentro de un código dado. Podemos lograr tal restricció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 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 combinaciones representarían de forma no ambigua un producto listado más de una vez para un único zip. En otras palabras, un procesador de esquemas podría detectar violaciones de la restricció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 nuestra definició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 de los elementos zip identificados por regiones/zip:

 <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 queremos asegurar que cualquier elemento cantidad-producto listado bajo un código zip tiene una descripción de producto correspondiente. Imponemos la restricción utilizando los elementos key [clave] y keyref [referencia clave]. El esquema de informes report.xsd, muestra que las construcciones key y keyref son aplicadas utilizando casi la misma sintaxis que unique. Los elementos clave se aplican al valor del atributo numero de los elementos 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, no es anulable), y el nombre asociado con la clave, pNumClave, hace que ésta sea referenciable desde cualquier otro sitio.

Para asegurar que los elementos cantidad-producto tienen sus correspondientes descripciones de producto, decimos que el atributo numero ( <field>@numero</field>) de esos 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, pero significa que debe existir una pNumClave con el mismo valor.

Como te habrás imaginado por analogía con unique, es posible definir combinaciones de valores key y keyref. utilizando este mecanismo, podemos ir más allá del simple requerimiento de que los números de los productos sean iguales, y definir una combinación de valores que debe ser igual. Tales valores pueden ser de combinaciones de mú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 las definiciones 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 asociado con los atributos IDREF y IDREFS. Este mecanismo también está presente en el Esquema XML a través de los tipos simples ID, IDREF, y IDREFS que pueden ser utilizados para declarar atributos del estilo de los de XML 1.0. El Esquema XML también introduce mecanismo nuevos que son más flexibles y potentes. Por ejemplo, los mecanismos del Esquema XML pueden ser aplicados a cualquier contenido de elemento o atributo, sin importar su tipo. Por contra, ID es un tipo de atributo y por tanto no puede ser aplicado a atributos, elementos o a su contenido. Más aún, el Esquema facilita la posibilidad de especificar el ámbito dentro del cual se aplica la unicidad mientras que el ámbito de un ID es fijado a todo el documento. Finalmente, el Esquema facilita la posibilidad de crear keys o una keyref a partir de combinaciones del contenido de elementos y atributos mientras que 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 utilizado include así que el esquema de ipo.xsd podría hacer uso de las definiciones y declaraciones de address.xsd. No podemos usar include aquí porque sólo puede incluir declaraciones y definiciones de un esquema con el mismo espacio de nombres que el esquema en el que lo queremos incluir. Por tanto, el elemento include no identifica un espacio de nombres (aunque requiere un schemaLocation). El mecanismo de importación que describimos en esta sección es un mecanismo importante que permite que componentes de esquemas procedentes de diferentes partes puedan ser utilizados conjuntamente, y por tanto posibilita la validación de esquemas con contenido definido en múltiples espacios de nombres.

Para importar el tipo SKU y utilizarlo en el esquema de los informes, identificamos el esquema en el que SKU está definido, y asociamos ese espacio de nombres con un prefijo para 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 asociamos el espacio de nombres con el prefijo xipo utilizando una declaración de tipo estándar. El tipo simple SKU, definido en el espacio de nombres http://www.example.com/IPO, entonces puede ser referenciado como xipo:SKU en cualquiera de las definiciones y declaraciones del esquema.

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

<element ref="xipo:comentario"/>

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

<element ref="xipo:enviarA"/>

En ipo.xsd, comentario es declarado como un elemento global, en otras palabras es declarado como un elemento del schema. Por contra, enviarA es declarado localmente, en otras 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 tipos base para derivar tipos nuevos. Sólo se pueden importar tipos complejos con nombre; los tipos locales o definidos de forma anónima no pueden ser importados. Supongamos que queremos incluir en nuestros informes el nombre de un analista, junto con su información de contacto. Podemos reutilizar el tipo complejo (definido globalmente) direccionEEUU de address.xsd, y extenderlo para definir un tipo nuevo llamado Analista añadiendo los elementos nuevos telefono y email:

<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 la declaración del elemento informePedidos (no se muestran las declaraciones) en el esquema de los informes. Entonces, la siguiente instancia de documento conformaría con el esquema de informes modificado:

<informePedidos
  xmlns="http://www.example.com/Report"
  periodo="P3M" finPeriodo="1999-12-31">
  <!-- se han omitido regiones y números de productos -->
   <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>uhro@example.com</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 elementos import por si mismos deben aparecer como el primero de los hijos del elemento schema. Es más, cada espacio de nombres debe estar asociado con un prefijo, utilizar una declaración de espacio de nombres de tipo estándar, y que el prefijo sea utilizado para calificar referencias 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. Discutiremos el atributo schemaLocation con más detalle en una sección posterior.

<schema targetNamespace="http://www.example.com/Currency"
        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 Puls)
          </documentation>
         </annotation>
        </enumeration>
      
        <enumeration value="ALL">
         <annotation>
          <documentation xml:lang="es">
           Albania, Lek (1 Lek = 100 Qindarka)
          </documentation>
         </annotation>
        </enumeration>
      
        <!-- y otras monedas -->

      </restriction>      
     </simpleType>
    </attribute>
   </extension>
  </simpleContent>
 </complexType>

</schema>

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

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

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

Para ilustrarlo, consideremos una versión del informe trimestral, 4Q99html.xml, en la que hemos incluido una representación HTML de los datos XML de productos. El contenido HTML aparece como el contenido de el elemento ejemploHTML, y el espacio de nombres por defecto es cambiado en el elemento HTML más externo (table) por lo que todos los elementos pertenecen al espacio de nombres HTML, http://www.w3.org/1999/xhtml:

<informePedidos
  xmlns="http://www.example.com/Report"
  periodo="P3M" finPeriodo="1999-12-31">

 <regiones>
   <!-- ventas por piezas listadas por código zip, datos de 4Q99.xml -->
 </regiones>

 <productos>
   <!-- descripciones de productos de 4Q99.xml -->
 </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 el esquema del informe declarando un elemento nuevo ejemploHTML cuyo contenido es definido por el elemento any. En general, un elemento any especifica que cualquier XML bien 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 un elemento presente para este espacio de nombres, como se indica en los valores de minOccurs y maxOccurs:

<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 al espacio de nombres http://www.w3.org/1999/xhtml dentro del elemento ejemploHTML. Por 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 el documento instancia asegura que el elemento y su contenido pertenecen al espacio de nombres requerido. Sin embargo, el HTML podría no ser realmente válido porque no hay nada en 4Q99html.xml por si mismo que pueda proporcionar esa garantía. Si se requiere tal garantía, el valor del atributo processContents [proceso de contenidos] debería ser igual a strict [estricto] (el valor por defecto). En este caso, el procesador de XML está obligado a obtener el esquema asociado con el espacio de nombres requerido, y validar el HTML que aparece dentro del elemento ejemploHTML.

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

<xsd:complexType name="texto">
 <xsd:complexContent mixed="true">
  <xsd:restriction base="xsd:anyType">
   <xsd:sequence>
    <xsd:any processContents="lax" minOccurs="0" maxOccurs="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 de elementos de varias formas dependiendo del valor del atributo namespace, como se muestra en la Tabla 4:

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

<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/xhtml"/>
 </complexType>
</element>

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

....
  <ejemploHTML xmlns:h="http://www.w3.org/1999/xhtml"
               h:href="http://www.example.com/reports/4Q99.html">
     <!-- marcado HTML aquí -->
  </ejemploHTML>
....

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

5.6 schemaLocation [ubicación del esquema]

El Esquema XML utiliza los atributos schemaLocation y xsi:schemaLocation en tres circunstancias:

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

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

 <!-- etc. -->

</informePedidos>

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

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

2. En un esquema, el elemento include tiene un atributo schemaLocation obligatorio, y contiene una referencia URI que debe identificar a un esquema. El efecto es componer un esquema final efectivo mediante la mezcla de las declaraciones y definiciones de los esquemas 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 con las declaraciones de sus elementos y atributos locales) de address.xsd fueron añadidas a las declaraciones de los elementos de hojaPedido y comentario, y las definiciones de tipo de TipoHojaPedido, Elementos y SKU (junto con las declaraciones de sus elementos y atributos locales) de ipo.xsd para crear un único esquema.

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

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

5.7 Concordancia

Un documento instancia puede ser procesado contra un esquema para verificar que las reglas especificadas en el esquema son cumplidas por la instancia. Típicamente, tal proceso hace dos cosas, (1) comprueba la corcondancia con las reglas, un proceso llamado 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, llamados contribuciones al conjunto de información.

El autor de un documento instancia, tal como una hoja de pedido concreta, puede especificar, en la misma instancia, que conforme (concuerde) con las reglas de un esquema particular. El autor hace esto utilizando el atributo schemaLocation discutido anteriormente. Pero sin importar si un atributo schemaLocation está o no presente, una aplicación es libre de procesar el documento contra cualquier esquema. Por ejemplo, una aplicación de pedidos pude tener la política de utilizar siempre el mismo esquema determinado 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 contenidos adecuados, entonces se comprueba que cada subelemento conforma con su descripción en el esquema, y así hasta que el documento completo se verifica. Los procesadores deben informar de qué tipo de comprobaciones han llevado a cabo.

Para comprobar la concordancia de un elemento, el procesador primero localiza la declaración del elemento targetNamespace en el esquema, y entonces comprueba que el atributo 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 atributo targetNamespace y que el elemento de la instancia no está calificado.

Suponiendo que los espacios de nombres concuerden, el procesador entonces examina el tipo del elemento, ya sea el dado por la declaración en el esquema o el del atributo xsi:type en la instancia. Si se da este último caso, el tipo de la instancia debe ser de un tipo que pueda ser sustituido por el dado en el esquema, lo que es permitido se controla mediante el atributo block en la declaración del elemento. En ese mismo momento, se aplican 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 del elemento, comparando estos valores con los permitidos por el tipo del elemento. Por ejemplo, consideremos un elemento enviarA tal como el de la Sección 2.1, el procesador comprueba lo que es permitido para una direccion, porque ese es el tipo del elemento enviarA.

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

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

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