XML Schema, o XSD, es un lenguaje que describe la estructura de un documento XML.


XSD es utilizado para describir la estructura y las restricciones de los contenidos de los documentos XML de una forma muy precisa, más allá de las normas sintácticas impuestas por el propio lenguaje XML.


Un documento XML que tenga una sintaxis correcta se dirá que está "bien formado", mientras que un documento validado contra un XSD sería tanto "bien formado" como "válido".

Gracias a XSD podemos definir una descripción del formato correcto que debe tener un XML y además, dicho formato está descrito también en formato XML. Posteriormente, usando el mismo XSD, podemos verificar si un mensaje XML determinado cumple con el formato definido y es válido.

Los XSD además soportan tipos de datos, una de sus grandes ventajas dado que nos facilita la descripción del contenido del documento, la definición de restricciones en los datos, las validaciones de si los datos son correctos y la conversión de datos entre diferentes tipos de datos.

Sintáxis de XML Schema

El esquema de ejemplo de la derecha se interpretaría de la siguiente manera:
<xs:element name="note"> define el elemento llamando "note"

<xs:complexType> el elemento "note" es de tipo complejo (no es un nodo con un sólo valor)

<xs:sequence> el tipo complejo es una secuencia de elementos 

<xs:element name="to" type="xs:string"> define el elemento "to" de tipo cadena de caracteres (texto)

<xs:element name="from" type="xs:string"> define el elemento "from" de tipo texto

<xs:element name="heading" type="xs:string"> define el elemento "heading" de tipo texto 

<xs:element name="body" type="xs:string"> define el elemento "body" de tipo texto



XSD en i2factory

i2factory hace uso de los XSD en los comando de cada tipo de puerto que disponga un conector específico, de tal manera que se informa a la solución de integración que esquema de mensaje va a recibir (puerto de entrada) o que esquema de mensaje debe de emitir (puerto de salida). La información de cada XSD puede verse en la información adicional de cada comando una vez seleccionado, haciendo click en el icono

 


 <xs:element name="note">
 
<xs:complexType>
  <xs:sequence>
    <xs:element name="to" type="xs:string"/>
    <xs:element name="from" type="xs:string"/>
    <xs:element name="heading" type="xs:string"/>
    <xs:element name="body" type="xs:string"/>
  </xs:sequence>
</xs:complexType>
 
</xs:element>

tNOM6I062rZRYIHy5wzv_aaPXWy-9EnR_Q.pngCampos obligatorios y no obligatorios
Si en alguna definición de un elemento aparece el atributo minOccurs="0" significa que ese elemento es opcional y no es requerido por el validador del XSD, es decir, no debe ser incluido obligatoriamente (puede estar en el mensaje o no).
Si por el contrario, en alguna definición de un elemento aparece el atributo minOccurs="1" significa que ese elemento es obligatorio y es requerido por el validador del XSD y por tanto debe estar en el mensaje.
El valor por defecto del atributo minOccurs = 1, por lo que sino aparece nada quiere decir que ese campo es obligatorio.


Ejemplo de XSD en i2factory

Vamos a ver un ejemplo real de uso en i2factory de los XSD.

En este ejemplo vamos a ver el esquema XSD del comando "Obtener todos los archivos y carpetas" del puerto de entrada del conector de Dropbox:

  • Se define que el nodo raíz del mensaje de entrada va a ser el elemento FileDropboxBean, que es de tipo complejo y compuesto por una secuencia de los siguientes elementos de tipos simples:

  • fileName: hace referencia al nombre del fichero o carpeta que se está leyendo y es de tipo texto

  • fileSize: hace referencia al tamaño del fichero o carpeta que se está leyendo y es de tipo texto. No es obligatorio que esté presente.

  • isDeleted: es un valor lógico que indica si el fichero o carpeta fué borrado con anterioridad. No es obligatorio que esté presente.

  • isDir: es un valor lógico que indica si el elemento se trata de un fichero (valor falso) o una carpeta (valor cierto).

  • modified: hace referencia a la fecha de modificación del fichero o carpeta que se está leyendo y es de tipo texto. No es obligatorio que esté presente.

  • path: hace referencia a la ruta desde la carpeta raíz al elemento que se está leyendo y es de tipo texto. 
  • parentFolder: hace referencia a la carpeta contendora del elemento que se está leyendo y es de tipo texto. 
  • revision: hace referencia al número de versión del fichero o carpeta que se está leyendo y es de tipo texto. No es obligatorio que esté presente.
  • extension: hace referencia a la extensión del archivo que se está leyendo, en caso de tratarse de un fichero, y es de tipo texto. No es obligatorio que esté presente (por ejemplo en caso de leer una carpeta).
  • file: este elemento contiene el contenido en formato binario (base 64 bits) del fichero, en caso de que se esté leyendo un archivo. No es obligatorio que esté presente (por ejemplo en caso de leer una carpeta. 







<?xml version="1.0" encoding="UTF-8"?>
 
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 attributeFormDefault="unqualified" elementFormDefault="qualified"
 version="1.0">
 
  <xsd:element name="FileDropboxBean">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="fileName" type="xsd:string"  />
        <xsd:element name="fileSize" type="xsd:string" minOccurs="0"  />
        <xsd:element name="isDeleted" type="xsd:boolean" minOccurs="0"  />
        <xsd:element name="isDir" type="xsd:boolean"  />
        <xsd:element name="modified" type="xsd:string" minOccurs="0"  />
        <xsd:element name="path" type="xsd:string"  />
        <xsd:element name="parentFolder" type="xsd:string"  />
        <xsd:element name="revision" type="xsd:string" minOccurs="0"  />
        <xsd:element name="extension" type="xsd:string" minOccurs="0"  />
        <xsd:element name="file" type="xsd:base64Binary" minOccurs="0"  />
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

Podemos acceder a la información del esquema de cada comando en el propio i2factory Studio:

XGXH9a_fxA64IHmX8SV1jp0Kn-CPBnEr1g.png

Y al pinchar sobre los slots de comunicaciones tanto en el área de modelado como en el depurador, podemos ver el esquema de modo gráfico. Si ejecutamos el 

depurador podemos comprobar cómo los mensajes cumplen con los esquemas definidos:

  

Esquema del comando "Obtener todos los archivos
y carpetas" del puerto de entrada de Dropbox:

HMBuD5NiqT5YySq-AuKlJziNHeqsrm3LrA.png

 Esquema de un mensaje entrante del comando
"Obtener todos los archivos y carpetas"
del puerto de entrada de Dropbox:

yqDBsxqtoOy_gdfCx02iczZ3i8RDsXi9Cw.png
Esquema de otro mensaje entrante del comando
"Obtener todos los archivos y carpetas":

dU40kmJeuENZLkXlLDkcllXv6cfbpvKWqQ.png



En el caso del primer mensaje entrante, el puerto ha leído un directorio o carpeta (elemento isDir con valor true) por lo que campos como fileSize vale 0 y no están presentes 

campos opcionales como modified o revision.

En el segundo caso, por el contrario, lo que el comando procesa es un fichero de imagen (elemento extension a jpg)  por lo que contiene los campos opcionales modfied, 

revision o incluso el propio elemento file que tiene como valor el contenido del fichero de imagen en formato binario de 64 bits.

Ambos mensajes cumplen con el esquema XSD definido previamente en el comando del conector de Dropbox, por lo que están bien formados y son válidos.