0% encontró este documento útil (0 votos)
171 vistas19 páginas

Guía de Validación XML y DTD

Este documento explica la validación de documentos XML. Define la validación XML como la comprobación de que un documento XML está bien formado y se ajusta a una estructura definida en un DTD o XSD. Explica que un DTD describe la estructura de un documento XML y que puede contener reglas internas o hacer referencia a reglas externas. También describe los elementos básicos para definir un DTD como elementos, atributos, entidades y notaciones.

Cargado por

Cristina León
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
171 vistas19 páginas

Guía de Validación XML y DTD

Este documento explica la validación de documentos XML. Define la validación XML como la comprobación de que un documento XML está bien formado y se ajusta a una estructura definida en un DTD o XSD. Explica que un DTD describe la estructura de un documento XML y que puede contener reglas internas o hacer referencia a reglas externas. También describe los elementos básicos para definir un DTD como elementos, atributos, entidades y notaciones.

Cargado por

Cristina León
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd

1 Validación XML

1.1 ¿Qué es la validación XML?


La Validación XML es la comprobación de que un documento en lenguaje XML está bien formado y se ajusta a una
estructura definida en un DTD o en un XSD.

1.2 Formas de validar un documento XML


▪ DTD (Document Type Definition): es un metalenguaje definido ya para SGML que permite describir la
estructura y sintaxis de un documento XML o SGML.
▪ XML Schema : es un lenguaje escrito en XML, desarrollado con posterioridad a las DTD, y pensado para
proporcionar mayor potencia expresiva que DTD. Su principal diferencia con las DTD es que XML soporta la
definición de tipos de datos.

1.3 XML Bien formado Versus XML validado


Hasta ahora hemos visto cuales son las reglas para que un documento XML esté bien formado.  Para cada aplicación
existen unas reglas que establecen cuales son las relaciones entre elementos y atributos, los valores permitidos, etc. 
Así cada aplicación tiene un vocabulario concreto.   Un documento XML, además de estar bien formado, es válido
si existen unas reglas de validación asociadas y el documento las cumple.  Todo documento XML válido está bien
formado pero no al revés: Un documento bien formado no tiene porque ser válido conforme a las reglas de validación. 

2 DTD ( Definición de tipo de documento )


Un DTD es una descripción de la estructura de un documento XML. Se especifica que elementos deben aparecer, en qué
orden, cuáles son optativos, cuales obligatorios, que atributos tienen los elementos, etc.

2.1 Elementos para especificar un tipo de documento dentro de un XML


Para especificar un tipo DTD para un documento XML hay que incluir dos cosas: 

▪ La declaración del tipo de documento: es la parte donde decimos a qué tipo pertenece nuestro documento,
y se incluye en el prólogo del documento XML. Utiliza la etiqueta <!DOCTYPE>
▪ La definición del tipo de documento: es la parte donde se definen todas la reglas que aplican al tipo
mediante ciertas estructuras especiales denominadas declaraciones de marcado. Toda declaración de tipo
propiamente dicha para un documento se complementa con una definición del tipo (abreviada como DTD)
que asocia al tipo las cualidades que posee. La DTD define los tipos de elementos, atributos, entidades y
notaciones que se podrán utilizar en el documento, así como ciertas restricciones estructurales y de
contendido, valores por defecto, etc. Para formalizar todo ello XML provee ciertas estructuras especiales, las
llamadas declaraciones de marcado y que pertenecen a alguno de los siguientes tipos: 

▪ Elementos.  La declaración se hace con la etiqueta <!ELEMENT>


▪ Atributos.  La declaración se hace con la etiqueta <!ATTLIST>
▪ Entidades. La declaración se hace con la etiqueta <!ENTITY>
▪ Notación. La declaración se hace con la etiqueta <!NOTATION>

Las declaraciones incluidas en la DTD pueden ser: 

▪ Internas: se encuentran dentro del propio documento XML; forman lo que se denomina el subconjunto
interno.
▪ Externas: se encuentran en un fichero separado; forman el subconjunto externo
▪ Una combinación de ambas. Hay parte fuera y parte dentro.  Tienen preferencia las internas sobre las
externas.
Validación XML 1
En el ejemplo que se muestra a continuación se destaca un DTD interno (incluido dentro del propio documento ):

2.1.1 DTD interno


<?xml version="1.0" encoding="UTF-8" ?> 
<!DOCTYPE Casas_Rurales [ 
<!ELEMENT Casas_Rurales (Casa)*> 

<!ELEMENT Casa (Dirección, Descripción, Estado, Tamanio)> 


<!ELEMENT Dirección (#PCDATA) > 
<!ELEMENT Descripción (#PCDATA) > 
<!ELEMENT Estado (#PCDATA) > 
<!ELEMENT Tamanio (#PCDATA) > 

]> 
<Casas_Rurales> 
... 
</Casas_Rurales> 

2.2 La declaración de un DTD


Es la instrucción donde se indica qué DTD validará el XML.  Aparece al comienzo del documento XML, antes del
primer dato que aparece, que es el nombre del elemento raíz del documento XML.  En función del tipo de DTD la
sintaxis varía.  Las características que definen el tipo son:

▪ Ubicación donde se localiza el DTD. Puede ser:

▪ Interno. Las reglas del DTD aparecen en el propio documento XML.


▪ Externo.   Las reglas aparecen en un archivo independiente.
▪ Mixto. Las reglas aparecen en ambos lugares: dentro del documento XML y en un fichero externo. Las
reglas internas tienen prioridad sobre las externas.
▪ Carácter del DTD.
▪ para uso privado.  Se itentifica con la palabra SYSTEM.
▪ Para uso público. Se identifica con la palabra PUBLIC. Debe ir acompañada de un FPI, una etiqueta
que identifica el DTD de forma universal.

Las distintas combinaciones son: 

 Sintaxis Tipo de DTD 

 <!DOCTYPE elemento_raíz [reglas]>  Interno (luego privado)

 <!DOCTYPE elemento_raíz  SYSTEM URL>  Externo y privado

<!DOCTYPE elemento_raíz  SYSTEM URL [reglas]>  Mixto y privado

 <!DOCTYPE elemento_raíz  PUBLIC FPI URL>  Externo y público

 <!DOCTYPE elemento_raíz  PUBLIC FPI URL [reglas]>  Mixto y público

2.3 Subconjunto interno


Como ya sabemos, si las declaraciones de marcado están incluidas dentro del documento de partida forman el
llamado subconjunto interno. En este caso, dichas declaraciones se incluyen dentro de unos corchetes que siguen a la
declaración del tipo del documento, de la siguiente manera: 
Validación XML 2
<!DOCTYPE NombreXML [ 
... 
]> 

El subconjunto interno contiene declaraciones que pertenecen únicamente a un documento, que son específicas para
él y que no es posible compartir. 

Para ilustrar esto, vamos a añadir algunas declaraciones de tipos de elementos internas al ejemplo anterior. No
es necesario entender todas las declaraciones en este momento, ya las iremos explicando todo poco a poco. 
<?xml version="1.0" encoding="UTF-8" ?> 
<!DOCTYPE Casas_Rurales [ 
<!ELEMENT Casas_Rurales (Casa)*> 

<!ELEMENT Casa (Dirección, Descripción, Estado, Tamanio)> 


<!ELEMENT Dirección (#PCDATA) > 
<!ELEMENT Descripción (#PCDATA) > 
<!ELEMENT Estado (#PCDATA) > 
<!ELEMENT Tamanio (#PCDATA) > 

]> 
<Casas_Rurales> 
... 
</Casas_Rurales> 

La definición del tipo anterior especifica que el tipo de documento Casas_Rurales está formado por elementos de
tipo Casa. Los elementos de tipo Casa contienen a su vez elementos de tipo Dirección, Descripción, Estado y Tamanio,
en este orden y sin faltar ninguno. El contenido de estos elementos está formado exclusivamente por datos carácter
(#PCDATA). 
Para acabar de completar el documento XML del ejemplo, incluiremos el contenido del ejemplar del documento. Se

puede comprobar cómo el ejemplar cumple con las restricciones de tipo, estructura  y contenido especificadas. 
<?xml version="1.0" encoding="ISO-8859-1" ?> 
<!DOCTYPE Casas_Rurales [ 
<!ELEMENT Casas_Rurales (Casa)*> 

<!ELEMENT Casa (Dirección, Descripción, Estado, Tamanio)> 


<!ELEMENT Dirección (#PCDATA) > 
<!ELEMENT Descripción (#PCDATA) > 
<!ELEMENT Estado (#PCDATA) > 
<!ELEMENT Tamanio (#PCDATA) > 

]> 
<Casas_Rurales> 
<Casa> 
<Dirección>Calle Las Palmas 23. La Sagra. Toledo</Dirección> 
<Descripción> 
Se trata de una casa del siglo XVII, ... 
</Descripción> 
<Estado>El estado de conservación es magnífico, ...</Estado> 
<Tamanio>La casa tiene 259 metros cuadrados, ...</Tamanio> 
</Casa> 
<Casa> 
<Dirección>Calle Or 5, Fregenal de la Sierra. Badajoz 
</Dirección> 
<Descripción> 
De arquitectura espectacular la casa ... 
</Descripción> 
<Estado>Recientemente restaurada su estado actual es ... 
</Estado> 
<Tamanio>La superficie habitable es de ...</Tamanio> 
</Casa> 
</Casas_Rurales> 

Validación XML 3
2.3.1 Subconjunto externo
Las declaraciones de marcado también pueden encontrarse fuera del documento XML. Estas declaraciones de
marcado externas pueden referenciarse de varias maneras: 

● Mediante una declaración explícita de subconjunto externo. Mediante entidades parámetro externas.
● La segunda forma se estudiará más adelante en el apartado dedicado a las entidades y a las declaraciones de
entidades.

Normalmente el subconjunto externo está formado por declaraciones comunes que se comparten entre múltiples
documentos XML que pertenecen al mismo tipo. Se escriben y modifican una vez en lugar de tener que repetirla y
modificarla muchas veces. 
Ahora los corchetes pierden su sentido y a cambio se impone utilizar algún sistema de referencia que permita
localizar las declaraciones de marcado externas. Para el subconjunto externo la declaración del tipo del documento
puede tomar alguna de las siguientes formas: 
<!DOCTYPE NombreXML SYSTEM "URI" > 
<!DOCTYPE NombreXML PUBLIC "id_publico" "URI" > 

En la primera, detrás de la palabra SYSTEM se especifica un URI donde se pueden encontrar las declaraciones.
En la segunda forma se especifica también un identificador, que puede ser utilizado por el procesador XML para
intentar generar un URI alternativo, posiblemente basado en alguna tabla. Hay que notar que también es necesario
(obligatorio) especificar un URI. 

Podemos transformar el ejemplo de las casas rurales para que todas las declaraciones de los elementos sean
externas al documento. El URI en este ejemplo es absoluto pero podría haberse empleado uno relativo, si se desea
probar el ejemplo se puede cambiar el URI a uno relativo que incluyera únicamente el nombre del fichero
casasrurales.dtd, situando ambos ficheros en el mismo directorio. 
<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> 
<!DOCTYPE Casas_Rurales SYSTEM "http://www.casasrurales.com/casasrurales.dtd"> 
<Casas_Rurales> 
... 

</Casas_Rurales> 

Siendo el contenido del fichero casasrurales.dtd: 

<?xml version="1.0" encoding="ISO-8859-1" ?> 


<!ELEMENT Casas_Rurales (Casa)*> 

<!ELEMENT Casa (Dirección, Descripción, Estado, Tamanio)> 


<!ELEMENT Dirección (#PCDATA) > 
<!ELEMENT Descripción (#PCDATA) > 
<!ELEMENT Estado (#PCDATA) > 
<!ELEMENT Tamanio (#PCDATA) > 

La extensión ".dtd" del archivo es sólo una convención, no hay ninguna obligación en que así sea. 
Recordemos que un documento XML puede incluir en la declaración XML el campo “standalone”, con el que
indicamos si el documento es autónomo o no. Observar que si se incluye un subconjunto externo el documento ya no
puede ser autónomo, y por tanto el valor de “standalone” debe ser “no”, que es el valor por defecto.

2.4 Declaraciones elementos


● Elementos.  La declaración se hace con la etiqueta <!ELEMENT>
● Atributos.  La declaración se hace con la etiqueta <!ATTLIST>
<!ELEMENT nombre_elemento modelo_contenido>

Validación XML 4
Donde el nombre_elemento tiene que ser el mismo que el correspondiente del documento XML sin los signos < y >. 
El modelo de contenido puede contener:

Una regla  que puede ser:

▪ ANY.  Es un comodín que no debe aparecer en el DTD definitivo.  Se utiliza al construir un DTD para que valide
en cualquier caso.
▪ EMPTY. Describe un elemento vacío y sin descendientes. El elemento puede tener atributos.
▪ Datos de cualquier tipo  que no contengan etiquetas. Se utiliza para ello (#PCDATA). Los elementos
declarados como de tipo PCDATA no pueden contener los caracteres siguientes: 
▪ Elementos descendientes.  Se ponen entre paréntesis y siguen las reglas siguientes:

▪ Se indica la cardinalidad de los elementos (el número de veces que aparecen los elementos)
por ciertos símbolos:
▪ ? El elemento puede aparecer 0  o 1 vez.
▪ * El elemento puede aparecer 0 a N veces.
▪ + El elemento puede aparecer 1 a N veces.
▪ Se indican la secuencia de elementos que deben aparecer o los elementos alternativos.  Se
utilizan las reglas siguientes:
▪ A,B  indica que el elemento B aparecerá a continuación del A.
▪ A|B  indica que aparecerá el elemento A o el elemento B pero no ambos.
▪ Se pueden combinar los símbolos de cardinalidad con los de secuencia.

2.4.1 Definición de un elemento vacío


La descripción del elemento <br /> de html será:
<!ELEMENT br EMPTY>

2.4.2 Declaración de elementos para definir un correo electrónico


<!ELEMENT email (para, cc?, cco?, asunto, cuerpo)>
<!ELEMENT para (#PCDATA)>
<!ELEMENT cc (#PCDATA)>
<!ELEMENT cco (#PCDATA)>
<!ELEMENT asunto (#PCDATA)>
<!ELEMENT cuerpo (linea*)>
<!ELEMENT linea (#PCDATA)>

2.4.3 Definición del elemento grupoSanguineo


<!ELEMENT grupoSanguíneo (A|B|AB|0)>

2.4.4 Ejemplo de listado de discos con comentarios


<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE listado_discos [
<!ELEMENT listado_discos (disco)*>
<!ELEMENT disco (datos, descripcion, comentarios? )>
<!-- Declaración del tipo datos y todos los tipos que contiene-->
<!ELEMENT datos ((solista | grupo), titulo, anio?)>
<!ELEMENT solista (#PCDATA)>
<!ELEMENT grupo (#PCDATA)>
<!ELEMENT titulo (#PCDATA)>
<!ELEMENT anio (#PCDATA)>
<!-- Declaración del tipo descripcion y todos los tipos que contiene -->
<!ELEMENT descripcion (cancion)+>
<!-- Declaración del tipo de elemento cancion -->
<!ELEMENT cancion (#PCDATA)>
<!-- Declaración del tipo de elemento comentarios -->
<!ELEMENT comentarios (#PCDATA)>
]>

2.4.5 Ejemplos varios


<!ELEMENT aviso (parrafo)>
Indica que <aviso> sólo puede contener un solo <parrafo>.
 
Validación XML 5
<!ELEMENT aviso (titulo, parrafo)>
<aviso> debe contener un <titulo> seguido de un <parrafo>.
 
<!ELEMENT aviso (parrafo | grafico)>
<aviso> puede contener o bien un <parrafo> o bien un <grafico>. El númerode opciones no está limitado 
a dos, y se pueden agrupar usando paréntesis.
 <!ELEMENT aviso (titulo, (parrafo | grafico))>
<aviso> debe contener un <titulo> seguido de un <parrafo> o de un<grafico>.
 
<!ELEMENT aviso (titulo?, (parrafo+, grafico)*)>
En este caso, <aviso> puede  tener <titulo>, o no (pero sólo uno), y puede  tener cero o más conjuntos <par
rafo><grafico>, <parrafo><parrafo><grafico>, etc.

2.4.6 Ejercicios

2.4.6.1 Escribir la DTD que permita validar el documento XML que se muestra a continuación. Hacer dos versiones
en cada caso: DTD externa e interna. 

<?xml version="1.0" encoding="ISO-8859-1"?>

<etiqueta>

<nombre>Roberto García</nombre>

<calle>c/ Mayor, 27</calle>

<ciudad>Coslada</ciudad>

<pais>España</pais>

<codigo>39343</codigo>

</etiqueta>

2.4.6.2 Escribir la DTD que permita validar el documento XML que se muestra a continuación. Suponer que puede
haber varias etiquetas “para”. Hacer dos versiones en cada caso: DTD externa e interna. 

DOCUMENTO 1: 
<?xml version="1.0" encoding="ISO-8859-1"?> 
<!DOCTYPE nota SYSTEM "nota.dtd"> 
<nota> 
<para>Pedro</para> 
<de>Laura</de> 
<titulo>Recordatorio</titulo> 
<contenido>A las 7:00 en la puerta del teatro</contenido> 
</nota> 

2.5 Declaración de tipo de Atributo de DTD


Esta declaración indica la existencia de atributos en un elemento en el documento XML.  En general se
utiliza ATTLIST para declarar todos los atributos de un elemento, aunque se podría usar un ATTLIST para
cada atributo. La sintaxis general es:
<!ATTLIST nombre_elemento nombre_atributo tipo_atributo caracter>

nombre_elemento  es el nombre del elemento que tiene en XML y que tiene los atributos.
nombre_atributo es un nombre XML válido.
tipo_atributo puede ser
● CDATA: caracteres que no continen etiquetas. 

<!ATTLIST perro fecha_nacimiento CDATA "23-02-1988">

Validación XML 6
● Enumerado: una lista de valores(separados por | y de tipo token) entre los cuales el
atributo debe tomar uno. 
<!ATTLIST nom_elemento atributo (valor1 | valor2 |...)valor_por_defecto> 
Ejemplo
<!ATTLIST perro sexo (macho | hembra) "macho" > 
● ID:identificador único. Se usa para identificar elementos. Dos elementos no pueden
tener el mismo ID. Sólo pueden tene el caracter #IMPLIED o #REQUIRED. Un elemento
solo puede tener un ID y debe ser un nombre XML válido:
● IDREF: es el valor de un atributo ID de otro elemento, que debe existir en el
documento XML.
caracter puede ser:

▪ Un valor  textual entre comillas, que representa el valor por defecto del atributo.
▪ #IMPLIED, que indica que el atributo es de carácter opcional y no se le asigna ningún
valor por defecto.
▪ #REQUIRED, que indica que el atributo es de carácter obligatorio, pero no se le asigna un
valor por defecto.
▪ #FIXED, indica que el atributo es obligatorio y se le asigna una valor por defecto que
además es el único valor que puede tener el atributo.

2.5.1 Ejemplos
2.5.1.1 Regla para un semáforo que tiene un único atributo color
<!ELEMENT semaforo EMPTY>
<!ATTLIST semaforo color (rojo | amarillo | verde) "verde">

Los posibles valores son rojo, amarillo y verde y el valor por defecto es verde

2.5.1.2 Uso de IDREF utilizando un ID de otro elemento


<!ATTLIST empleado idEmpleado ID #REQUIRED idEmpleadoJefe IDREF #IMPLIED>

<!ATTLIST empleado idEmpleadoJefe IDREF #IMPLIED>

Con esta definición es válida los siguientes elementos XML:

<empleados>

<empleado idEmpleado="e111"> ... <empleado>


<empleado idEmpleado="e222" idEmpleadoJefe="e111"> ... <empleado>
.....

</empleados>

2.5.2 Ejercicios
2.5.2.1 Escribir la DTD que permita validar el documento XML que se muestra a continuación. Hacer dos versiones
en cada caso: DTD externa e interna. 

<lista_de_notas>
<nota>
<para>Pedro</para>
<de>Laura</de>
<titulo>Recordatorio</titulo>
<contenido>A las 7:00 pm en la puerta del teatro </contenido>
</nota>
<nota dia="23/01/2010" hora="13:15"> 
<para>Miguel</para> 
<de>Juan</de> 
<titulo>Informes</titulo> 
<contenido>Te he dejado los informes en el casillero</contenido> 
</nota> 
</lista_de_notas>
2.5.2.2 Escribir la DTD que permita validar el documento XML que se muestra a continuación. Hacer dos versiones
en cada caso: DTD externa e interna. 
<matricula>
Validación XML 7
  <personal>
    <dni>99223366M</dni>
    <nombre>Juan Pardo Martín</nombre>
    <titulacion>Ingeniería Informática</titulacion>
    <curso_academico>1997/1998</curso_academico>
    <domicilios>
      <domicilio tipo="familiar">
        <nombre>C/ Principal nº1</nombre>
      </domicilio>
      <domicilio tipo="habitual">
        <nombre>C/ Secundaria nº2</nombre>
      </domicilio>
    </domicilios>
  </personal>
  <pago>
    <tipo_matricula>Matrícula Ordinaria</tipo_matricula>
  </pago>
</matricula>
2.5.2.3 Escribir la DTD que permita validar el documento XML que se muestra a continuación correspondiente a un
Se el documento XML indicado a continuación. Construir un documento XML con DTD interna y otro con
DTD externa. Comprobar la buena formación y la validez del documento en ambos casos. El  DTD que
valide este documento debe tener en cuenta las siguientes características: 

▪ El título original de una película sólo aparecerá cuando la película no sea española. 
▪ Es posible que en un momento dado una pelicula esté pendiente de clasificación. En caso de que
esté clasificada siempre deberá indicar los años para los que se recomienda: tp (todos los públicos),
8, 12, 16 o 18. 
▪ No siempre existe una web con la información de la película. 
▪ Se quiere guardar información sobre el fichero gráfico que contiene el cartel de la película. Este
fichero no siempre está disponible. 
▪ En caso de que no se proporcione el año de una película se asumirá que es el 2003. 
▪ En el reparto deberá aparecer un actor como mínimo. 

<cartelera> 
<película código="p1" duración="152" año="2002"> 
<título>AQUELLAS JUERGAS UNIVERSITARIAS</título> 
<título_original>Old School</título_original> 
<nacionalidad>Estados Unidos</nacionalidad> 
<género>Comedia</género> 
<clasificación edad="tp"/> 
<sinopsis> 
Mitch, Frank y Beanie son tres amigos treintañeros cuyas vidas no son exactamente lo
que esperaban. Mitch tiene una novia ninfómana que se mete en la cama con el primero
que agarra. Frank se ha casado y su matrimonio nada 
tiene que ver con las juergas salvajes que organizaban años atrás. Y Beanie es 
un padre de familia que se muere por recuperar su alocada juventud. Pero las cosas
cambian cuando Beanie sugiere que creen su propia fraternidad, en la nueva casa que
Mitch tiene junto al campus de la universidad. Una ocasión para revivir tiempos
gloriosos, hacer nuevos amigos y de volver a sus viejas, salvajes y desmadradas juergas
de estudiantes. 
</sinopsis> 
<director>Todd Philips</director> 
<reparto> 
<actor>Luke Wilson</actor> 
<actor>Will Farrel</actor> 
<actor>Vince Vaughn</actor> 
</reparto> 
<web>http://www.uip.es</web> 
<cartel>caratulas/Aquellas juergas.jpg</cartel> 
</película> 
<película código="p17" duración="06"> 
<título>EL ORO DE MOSCÚ</título> 

Validación XML 8
<nacionalidad>España</nacionalidad> 
<género>Comedia</género> 
<sin_clasificar/> 
<sinopsis> 
Por una extraña coincidencia del destino, alguien recibe una información
extraconfidencial de un anciano en sus últimos segundos de vida: el secreto mejor
guardado de la Historia. El receptor, un trabajador de hospital, se lo comunica
secretamente a un supuesto amigo. Ambos inician una aventura rocambolesca y llena de
misterio. Ante la inutilidad de sus intentos y muy a 
su pesar, tienen que recurrir a otras personas que así mismo van cayendo en el pozo sin
fondo que conlleva descifrar el enigma. 
</sinopsis> 
<director>Jesús Bonilla</director> 
<reparto> 
<actor>Jesús Bonilla</actor> 
<actor>Santiago Segura</actor> 
<actor>Alfredo Landa</actor> 
<actor>Concha Velasco</actor> 
<actor>Antonio Resines</actor> 
<actor>Gabino Diego, María Barranco</actor> 
<actor>María Barranco</actor> 
</reparto> 
</película> 
</cartelera>

Validación XML 9
3 Referencia de XSDs. XML Schema Definition
3.1 Ventajas de XSD sobre DTD
▪ Un esquema es un documento XML y, por tanto, se puede comprobar que está bien formado.
▪ Tiene gran número de tipos de datos y atributos predefinidos que se pueden ampliar o restringir con la
creación de nuevos tipos.
▪ Se puede determinar con precisión la cardinalidad de un elemento, es decir, el número de veces que aparece
en un documento.

▪ Permite utilizar varios espacios de nombres, esto permite mezclar distintos vocabularios o juegos de etiquetas.

Ejemplo DTD vs XSD

3.2 Conceptos Básicos de XSD


3.2.1 Estructura básica
<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">

….

</xs:schema>

3.2.2 Extensión de los archivos con esquemas:


.xsd

3.2.3 Elementos
<xs:element name=””>

</xs:element

3.2.3.1 Elementos simples


<xs:element name=”” type=””>

</xs:element>

3.2.3.2 Elementos complejos ( puede contener atributos, elementos hijo y contenido mixto )
<xs:element name="">
<xs:complexType>
</xs:complexType>
</xs:element>
3.2.3.3 Secuencia ( xs:sequence )
Define una secuencia ordenenada de elementos, equivale a la “, “ en DTD

<xs:element name="emisor">
<xs:complexType>
<xs:sequence>
<xs:element name="nombre" type="xs:string"/>
<xs:element name="CIF" type="xs:string"/>
<xs:element name="telefono" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>

Permite definir el mínimo y el máximo número de ocurrencias con minOccurs y maxOccurs


<xs:element name="articulo"minOccurs=”1” maxOccurs=”unbounded” >
Validación XML 10
3.2.3.4 Choice ( xs:choice )
Define un grupo mutuemente excluyente, equivale a | de DTD

3.2.4 Atributos
Se utiliza la etiqueta <xs:attribute name=”” type=””> (no se cierra)

Reglas:

● Aparece después de la declaración de los subelementos


● Siempre tiene un tipo simple
● No puede contener hijos
● Su declaración no impone un orden
● Si no se define un tipo, será del tipo: anySimpleType. ( Cualquier cadena de caracteres válidos )
● Si no se dice nada es opcional
● Tiene a su vez tres atributos para restringir los valores: use, default y fixed
o use:
▪ required: el atributo es obligatorio

▪ optional: puede o no aparecer ( es el valor por defecto )


o default:
▪ valor por defecto del atributo
o fixed:
▪ valor fijo. Puede aparecer o no, pero si aparece solo puede tener ese valor.

3.2.4.1 Ejemplo de atributos en elementos simples

3.2.4.2 Ejemplo de atributos en elementos complejos

Habría que definir un elemento complejo compuesto a


su vez por un elemento simple con un una extension
de contenido simple basado en: un tipo simple + un
atributo.

Validación XML 11
3.2.5 Tipos de datos simples ( Ver todos los tipos simples )
Los tipos de datos se asignan con el atributo type=

Tipo anyType

No impone ninguna restricción. Por tanto es lo mismo:

<xs:element name=”nombre” type=”xs:anyType”/> = <xs:element name=”nombre” />

▪ Tipos cadena

▪ string: secuencia de longitud finita de caracteres*


▪ anyURI: una uri estándar de Internet
▪ NOTATION: declara enlaces a contenido externo no-XML
▪ Tipos numéricos
▪ decimal: número decimal de precisión (dígitos significativos) arbitraria *
▪ integer: números enteros
▪ float: número de punto flotante de 32 bits de precisión simple *
▪ double: número de punto flotante de 64 bits de doble precisión *
▪ Tipos de fecha/hora
▪ duration: duración de tiempo
▪ dateTime: instante de tiempo específico, usando calendario gregoriano, en formato
"YYYYMM-DDThh:mm:ss"
▪ date: fecha específica del calendario gregoriano, en formato "YYYY-MM-DD” *
▪ time: una instancia de tiempo que ocurre cada día, en formato "hh:mm:ss"
▪ gYearMonth: un año y mes del calendario gregoriano
▪ gYear: año del calendario gregoriano
▪ gMonthDay: día y mes del calendario gregoriano
▪ gMonth: un mes del calendario gregoriano
▪ gDay: una fecha del calendario gregoriano (día)

Validación XML 12
3.2.6 Definición de tipos de datos
3.2.7 Tipos complejos
La forma más sencilla de crear un nuevo tipo es crear un elemento complexType al que se le asigna un nombre
mediante el atributo “name”. Ejemplo:
<xsd:complexType name=”precioInfo”>

<xsd:sequence>

<xsd:element ref=”precioTipo”/>

<xsd:element ref=”precioN”/>

</xsd:sequence>

</xsd:complexType>

<xsd:element name=”precioTipo” type=”xsd:string”/>

<xsd:element name=”precioN” type=”xsd:decimal”/>

Con esto creamos un tipo nuevo llamado “precioInfo” que está formado por una secuencia de dos elementos,
“precioTipo” y “precioN”, a los que referencia. Podremos utilizar este tipo que hemos creado para definir elementos,
por ejemplo:
<xsd:element name=”precio” type=”precioInfo”/>

Observamos que en la definición del elemento precio, el nombre del tipo “precioInfo” no lleva el prefijo “xsd”, porque
no pertenece al espacio de nombres del estándar XML Schema. La principal ventaja de definir tipos de datos propios
es, por un lado, que estos tipos se pueden utilizar donde se quiera, y además, que estos tipos se pueden utilizar como
tipos base para definir otros tipos.

3.2.8 Crear un tipo por restricción de un tipo simple predefinido (xsd:restriction) ( FACETAS )
La forma más sencilla de crear un nuevo tipo a partir de uno ya existente es añadir condiciones a alguno de los tipos
predefinidos en el XML Schema. Esto se hace con el elemento <xsd:restriction>. Por ejemplo:
<xsd:simpleType name="monedaUSA">

<xsd:restriction base="xsd:decimal">

<xsd:fractionDigits value="2"/>

</xsd:restriction>

</xsd:simpleType>

En este ejemplo creamos un nuevo tipo simple y le asignamos el nombre “monedaUSA”. Mediante el uso del
elemento “xsd:restriction” definimos el tipo “monedaUSA” como un subtipo del tipo base “xsd:decimal”, en el que el
número de cifras decimales es 2 (xsd:fractionDigits value=”2”). Las restricciones (también llamadas facetas) que
pueden aplicarse a los tipos simples son:

▪ minInclusive: mínimo valor que puede tomar el número; por ejemplo, si mininclusive vale 5, el número tiene
que ser mayor o igual que 5.
▪ minExclusive: el número debe ser mayor que este valor; por ejemplo, si minExclusive vale 5, el número debe
ser mayor que 5.
▪ maxInclusive: máximo valor que puede tomar el número; por ejemplo, si maxinclusive vale 5, el número
tiene que ser menor o igual que 5.
▪ maxExclusive: el número debe ser menor que este valor; por ejemplo, si maxExclusive vale 5,el número debe
ser menor que 5.

Validación XML 13
▪ totalDigits: total de cifras en el número, incluyendo las enteras y las decimales.
▪ fractionDigits: número de cifras decimales.
▪ length: número de unidades del valor literal; para la mayoría de los tipos (por ejemplo los tipos “string” y sus
derivados, la faceta “length” se refiere a caracteres, pero para listas (que veremos más adelante) se refiere al
número de elementos en la lista, y para valores binarios se refiere al número de octetos. No se puede aplicar
a los tipos “integer”, “float” o “double” (para estos se puede utilizar “totalDigits”).
▪ minLength y maxLength: valor mínimo y máximo respectivamente para la faceta “length”.
▪ pattern: formato que debe tener el valor, especificado mediante una expresión regular tradicional.
▪ enumeration: conjunto de posibles valores que puede tomar el dato (lo veremos en el siguiente apartado)
▪ whiteSpace: controla la forma que tendrá el contenido de este dato una vez haya sido procesado; puede
tomar los siguientes valores:

▪ “preserve”: los datos no se modifican, quedan tal y como aparecen escritos.


▪ “replace”: los tabuladores, saltos de línea y retornos de carro son sustituidos por espacios.
▪ “collapse”: hace lo mismo que “replace”, pero además sustituye espacios múltiples por un solo
espacio.

3.2.8.1 Ejemplos
Estas facetas se pueden combinar, y se pueden usar tanto en las definiciones de tipos con nombre como en las
definiciones de elementos. Veamos algunos ejemplos, en los que las facetas se aplican a definiciones de e
lementos. Ejemplo 1: facetas “minInclusive” y “maxInclusive”.
<xs:element name="edad">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="120"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
Define el elemento “edad” de tipo simple, como un entero en el rango [0-120].
Ejemplo 2: facetas “minLength” y “maxLength”.
<xs:element name="contraseña">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:minLength value="5"/>
<xs:maxLength value="8"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

Validación XML 14
3.2.8.2 Patrones para “pattern”

3.2.8.2.1 Ejemplo ( máscara de un dni ):


<xs:simpleType name="dni">
    <xs:restriction base="xs:string">
        <xs:pattern value="[0-9] [0-9] [0-9] [0-9] [0-9] [0-9] [0-9] [0-9] [A-Z]"/>
    </xs:restriction>
</xs:simpleType>

3.2.9 Crear un tipo enumerado (xsd:enumeration)


Una forma muy útil de utilizar facetas es crear tipos enumerados para limitar los valores que puede tomar
un elemento o atributo. Ejemplo:
<xsd:attribute name="demanda">

<xsd:simpleType>

<xs:restriction base="xsd:string">

<xs:enumeration value="bajo"/>

<xs:enumeration value="medio"/>

<xs:enumeration value="alto"/>

</xs:restriction>

</xs:simpleType>

</xsd:attribute>

Definimos el atributo “demanda” como una restricción del tipo base “xsd:string”, donde sólo existen tres
valores posibles: “alto”, “medio” y “bajo”. El atributo “demanda” debe tomar uno de estos tres valores.

Validación XML 15
3.3 Espacios de nombres
Un espacio de nombres XML es una recomendación W3C para proporcionar elementos y atributos con nombre único en una
instancia XML. Una instancia XML puede contener nombres de elementos o atributos procedentes de más de un vocabulario
XML. Si a cada uno de estos vocabularios se le da un espacio de nombres, se resuelve la ambigüedad existente entre elementos o
atributos que se llamen igual. Los nombres de elementos dentro de un espacio de nombres deben ser únicos.
Un espacio de nombres XML no necesita que su vocabulario sea definido, aunque es una buena práctica utilizar un DTD o un
esquema XML para definir la estructura de datos en la ubicación URI del espacio de nombres.

3.3.1 ¿Cómo se declara el uso de un de espacio de nombres?


Para definir un espacio de nombres al que pertenece un elemento se usa, dentro de la etiqueta de inicio de ese
elemento, el atributo XML reservado “xmlns”, cuyo valor debe ser un identificador uniforme de recurso (URI)∗, que es
el nombre del espacio de nombres. El formato genérico de una declaración de un espacio de nombres es el siguiente:
xmlns(:<prefijo>)?=<nombre_del_espacio_de_nombres(URI)>

El prefijo, que es opcional, es un alias que identifica al espacio de nombres. El prefijo de un espacio de nombres es
totalmente arbitrario; lo que define e identifica un espacio de nombres es, en realidad, el URI. Hay que destacar que
el URI no se interpreta realmente como una dirección; se trata como una cadena de texto por el analizador XML. Por
ejemplo:
xmlns:xhtml="http://www.w3.org/1999/xhtml"

Se declara el espacio de nombres “http://www.w3.org/1999/xhtml”, al que se le asigna el alias “xhtml”. Todos los


elementos que incluyan el prefijo “xhtml” antes del nombre pertenecerán a este espacio de nombres. Insistimos en
que los URI sólo se utilizan para que el nombre sea único, no son enlaces, ni tienen que contener información. En el
ejemplo anterior el propio “http://www.w3.org/1999/xhtml” no contiene código alguno, simplemente describe el
espacio de nombres XHTML a lectores humanos. El hecho de usar una URL (tal como
"http://www.w3.org/1999/xhtml") para identificar un espacio de nombres, en lugar de una simple cadena (como
"xhtml"), reduce la posibilidad de que diferentes espacios de nombres usen identificadores iguales. Los
identificadores de los espacios de nombres no necesitan seguir las convenciones de las direcciones de Internet,
aunque a menudo lo hagan. Un URI es una cadena corta de caracteres que identifica inequívocamente un recurso,
normalmente accesible en una red o sistema. Un URI (Uniform Resource Identifier) se diferencia de un URL en que
permite incluir en la dirección una subdirección, para identificar un fragmento del recurso principal

3.3.2 ¿Cómo referenciamos un espacio de nombres con prefijo?


Una vez que se ha declarado un espacio de nombres y se le ha asignado un alias o prefijo, para indicar que un
elemento pertenece a dicho espacio de nombres se antepone dicho alias seguido del carácter dos juntos “:” como
prefijo al nombre del elemento. Dicho prefijo debe aparecer tanto en la etiqueta de inicio como de cierre del
elemento. El alcance de la declaración de un prefijo de espacio de nombres comprende desde la etiqueta de inicio de
un elemento XML, en la que se declara, hasta la etiqueta final de dicho elemento XML. Se considera que la
declaración de espacios de nombres es aplicable al elemento en que se especifica y a todos los elementos dentro del
contenido de ese elemento, a menos que sea anulado por otra declaración de espacio de nombres. En las etiquetas
vacías, correspondientes a elementos sin "hijos", el alcance es la propia etiqueta.

3.3.3 Declaración de múltiples espacios de nombres


Se pueden declarar múltiples espacios de nombres para un mismo elemento, usando varias veces el atributo “xmlns”,
una por cada espacio de nombres que queremos declarar. Por ejemplo:
<?xml version="1.0" encoding=”ISO-8859-1”?>
<lb:libro xmlns:lb=”urn:loc.gov:libros” xmlns:isbn=”urn:ISBN:0-395-36341-6”>

<lb:titulo>Más barato que una Docena</lb:titulo>

<isbn:numero>1568491379</isbn:numero>

</lb:libro>

En este ejemplo se declaran dos espacios de nombres para el elemento “libro”, que son:
Validación XML 16
▪ “urn:loc.gov:libros” al que se asocia el prefijo “lb”: el elemento “titulo” y el propio elemento “libro” pertenecen a este
espacio de nombres.
▪ ”urn:ISBN:0-395-36341-6” asociado al prefijo isbn: a este espacio de nombres pertenece el elemento “numero”.

3.3.4 El espacio de nombres por defecto


Cuando la declaración del espacio de nombres no especifica el carácter dos puntos y el alias del espacio de nombres,
se está definiendo un espacio de nombres por defecto. Un espacio de nombres por defecto se aplica al elemento
donde está declarado (si ese elemento no posee prefijo de espacio de nombres), y a todos los elementos sin prefijo
dentro del contenido del ese elemento. El efecto de dicha declaración es anular cualquier declaración de nivel
superior del espacio de nombres por defecto, estableciendo su valor a "nulo". Los espacios de nombres por defecto
no se aplican directamente a los atributos. El espacio de nombres de un atributo sin prefijo es una función del tipo
del elemento al cual está adjunto, y al espacio de nombres (si hubiese alguno) de ese elemento. Si la referencia URI
de la declaración de un espacio de nombres por defecto está vacía (el valor del atributo “xmlns” es una cadena vacía),
entonces se considera que los elementos sin prefijo pertenecientes al ámbito de la declaración no están en ningún
espacio de nombres. Esto tiene el mismo efecto, dentro del ámbito de la declaración, que si no hubiera espacio de
nombres por defecto.En el siguiente ejemplo, los elementos no prefijados (“libro” y “titulo”) pertenecen al espacio de
nombres por defecto (”urn:loc.gov:libros”).
<?xml version="1.0" encoding=”ISO-8859-1”?>
<libro xmlns=”urn:loc.gov:libros” xmlns:isbn=”urn:ISBN:0-395-36341-6”>

<titulo>Más barato que una Docena</titulo>

<isbn:numero>1568491379</isbn:numero>

</libro>

3.3.5 El uso de los espacios de nombres


Los espacios de nombres se usan para combinar vocabularios y facilitan la incorporación de elementos no previstos
inicialmente. Los espacios de nombres se crearon para que no existieran colisiones entre los diferentes módulos de
software que eran capaces de reconocer las marcaciones (etiquetas y atributos) del lenguaje XML ya que los
diferentes documentos que contienen marcaciones de distintas fuentes independientes entre sí, solían tener
problemas de reconocimiento cuando habían sido creados para otros programas de software que, sin embargo,
utilizaban el mismo tipo de elemento o nombre de atributo. Una de las motivaciones para esta modularidad es que, si
existe un conjunto de marcaciones disponibles, que son entendibles y para las que existe software útil disponible, es
mejor la reutilización de estas marcaciones que el hecho de reinventar unas nuevas. Así, se consideró que
las construcciones de documentos debían tener nombres universales, cuyo ámbito se extendiera más allá del
documento que las contuviera. La especificación Namespaces XML describe un mecanismo, los espacios de nombres
XML, que lleva a cabo esta misión.

3.4 Relación entre Espacios de nombres y XML Schemas.


3.4.1 Dentro del XML schema.
3.4.1.1 Estándar XML Schema
Al crear un XML schema hacemos uso de los elementos y atributos especificados en el estándar de XML Schema. Para
que esto sea posible debemos incluir en el elemento raíz del esquema (el elemento “schema”) una referencia al
espacio de nombres “http://www.w3.org/2001/XMLSchema”. Esto se hace incluyendo el atributo “xmlns” en
el elemento “schema”:

• xmlns: identifica el espacio de nombres al que pertenecen los componentes incluidos en el esquema, asignando
opcionalmente un prefijo (este prefijo suele ser “xs” o “xsd”. Así, la sentencia
xmlns:xs=”http://www.w3.org/2001/XMLSchema”

indica que los elementos y tipos de datos utilizados en el esquema provienen del espacio de nombres
“http://www.w3.org/2001/XMLSchema”, al que se le asigna el prefijo “xs”.
Validación XML 17
3.4.1.2 Espacio de nombres propio
Además, podemos hacer que el esquema que estamos creando tenga asociado un espacio de nombres propio (target
namespace). Para ello se puede utilizar el atributo targetNamespace del elemento “schema”: que crea un espacio
de nombres al que pertenecen los elementos que se definen en el esquema. Por ejemplo:
targetNamespace:”http://www.prueba.es/esquema1”
3.4.1.3 Especificar si los elementos y atributos deben estar certificados
También se puede especificar si los elementos y los atributos declarados en él deben estar certificados por un espacio
de nombres, ya sea explícitamente mediante un prefijo o implícitamente de forma predeterminada, cuando se
utilicen en un documento instancia XML. Para ello se pueden utilizar los
atributos elementFormDefault y attributeFormDefault del elemento <xsd:schema>. Los posibles valores de estos
atributos son:

● “qualified”: indica que, en los documentos instancia XML que referencien a este esquema, los elementos (en
el caso de elementFormDefault)/atributos (en el caso de attributeFormDefault) del “target namespace”
deben estar cualificados con un prefijo.
● “unqualified”: Este es el valor por defecto. Indica que los elementos/atributos no necesitan estar prefijados
en el documento instancia.

3.4.2 En los documentos instancia XML


En los documentos instancia XML, la referencia a un esquema XML se hace mediante atributos en el elemento raíz del
documento instancia XML. Estos atributos, especificados en el estándar, se encuentran definidos en el espacio de
nombres “http://www.w3.org/2001/XMLSchema-instance”. Por lo tanto para poder usarlos hay que hacer referencia
a dicho espacio de nombres en el documento instancia XML, mediante el atributo “xmlns”. Normalmente a este
espacio de nombres se le asigna el prefijo “xsi” (aunque se puede usar cualquier prefijo), con lo que la referencia
al espacio de nombres quedaría así:
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

Con esto podemos utilizar los atributos “noNameSpaceLoction” y “schemaLocation”, que nos permiten asociar un
documento instancia XML con un esquema:

● noNamespaceSchemaLocation: identifica un documento de schema que no tiene un espacio de nombres de


destino (no incluye el atributo “targetNamespace”) y lo asocia al documento XML instancia.
● schemaLocation: Asocia un documento de esquema que tiene un espacio de nombres de destino
(targetNamespace) con un documento de instancia. Este atributo tendrá dos valores, separados por un
espacio en blanco. El primer valor coincide con el del “targetNamespace” especificado en el schema. El
segundo es la ubicación donde se encuentra definido el XML schema.

Por ejemplo, supongamos que tenemos el archivo “apuntes.xsd” que contiene un XML schema. Si en dicho schema se
definió
targetNamespace:”http://www.prueba.es/esquema1”

En un documento instancia que queremos asociar a este esquema tendremos:


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation:”http://www.prueba.es/esquema1 apuntes.xsd”

Si por el contrario en el documento “apuntes.xsd” no se especifica Un “targetNamespace”, en el documento instancia


XML tendremos:
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation=”apuntes.xsd”

Validación XML 18
Para establecer cual es el prefijo de un determinado espacio de nombres dentro del documento instancia (XML)
utilizaciones:
xmlns: prefijo= "espacio de nombres"

xmlns:apu="http://www.prueba.es/esquema1"

3.4.3 Ejemplo sencillo


Ejemplo de un documento XML al que asociamos un espacio de nombres.
<p:persona

     xmlns:p="http://www.prueba.es/persona"  

     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

     xsi:schemaLocation= "http://www.prueba.es/persona people.xsd"

     >

    <p:nombre>John</p:nombre>

    <p:direccion>John</p:direccion>

</p:persona>

El documento XSD que continue el espacio de nombres es people.xsd


<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.prueba.es/persona" 
elementFormDefault="qualified"             
attributeFormDefault="qualified">
  <xs:element name="persona">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="nombre" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element name="direccion" type="xs:string" minOccurs="0"
             maxOccurs="unbounded"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Validación XML 19

También podría gustarte