Este artículo ha sido consultado en 434 ocasiones.

Publicado originalmente en inglés por IBM developerWorks Traducido por Gratiniano Lozano para JavaHispano.org

Sección 1. Acerca de este tutorial

Este tutorial, recientemente revisado, discute lo que es XML, por qué fue desarrollado y como está definiendo el futuro del comercio electrónico. Llendo más lejos, echa un vistazo a diversos estándares XML e interfaces de programación, muestra cómo se puede empezar con esta tecnología y describe cómo un par de compañías han construido soluciones basadas en XML para simplificar y agilizar sus negocios. En este tutorial, usted aprenderá: · Porqué fue creado XML. · Las reglas de los documentos XML. · Cómo definir lo que puede y no puede contener un documento XML. · Programación de interfaces que trabajen con documentos XML. · Cuales son los principales estándares de XML y como trabajan juntos. · Como usan XML las compañías en el mundo real.

Acerca del autor

Doug Tidwell es Programador Senior y `evangelista' de IBM para los Servicios Web. Fue conferenciante en la primera conferencia sobre XML en 1997 y ha estado trabajando con lenguajes de marcado durante más de una década. Obtuvo una licenciatura en Ingles en la Universidad de Georgia y un Master en Informática en la Universidad de Vanderbilt. Se le puede encontrar en dtidwell@us.ibm.com. También podrá ver su página web en ibm.com/developerWorks/speakers/dtidwell/.

Sección 2. ¿Qué es XML? Introducción

XML, o Lenguaje de Marcado Extensible (Extensible Markup Language), es un lenguaje de marcado que puede usar para crear sus propias etiquetas. Fue creado por el Consorcio para la World Wide Web (W3C) para superar las limitaciones de HTML, el Lenguaje de Marcado de HiperTexto que es la base para todas las páginas Web. Aunque SGML ha sido usado durante décadas en la industria para publicación, su complejidad ha intimidado a mucha gente que, en otro caso, podría haberlo usado (SGML también vale como Suena Genial, Mejor Luego) (*N. del T.- interpretación libre de Sounds Great, Maybe Later). XML fue diseñado pensando en la Web.

¿Porqué necesitamos XML?

HTML es el lenguaje de marcado con más éxito del momento. Puede ver las etiquetas HMTL más simples en casi cualquier dispositivo, desde palmtops hasta los mainframes, e incluso puede convertir HTML en voz o en otros formatos con las herramientas adecuadas. Dado el éxito de HTML, ¿porqué la W3C creó XML?. Para responder a esta pregunta eche un vistazo a este documento.

<p><b>Mrs. Mary McGoon</b> <br> 1401 Main Street <br> Anytown, NC 34829

El problema con HTML es que fue diseñado pensando en los humanos. Incluso sin ver el documento anterior en un navegador, podemos imaginar que se trata de la dirección postal de alguien. (Específicamente, es una dirección postal de alguien en los Estados Unidos; incluso aunque no estuviese familiarizado con los componentes de las direcciones postales de Estados Unidos podría imaginarse lo que representa.) Como humanos, tenemos la inteligencia para comprender el significado e intención de muchos documentos. Una máquina, desafortunadamente no puede hacerlo. Mientras que las etiquetas de este documento le dicen al navegador cómo debe mostrar la información, no le dicen lo que la información es. Nosotros sabemos que es una dirección, pero la máquina no.

Representar HTML

Para representar HTML, el navegador únicamente sigue las instrucciones en el documento HTML. La etiqueta de párrafo le dice al navegador que empiece la presentación en una nueva línea, típicamente con una línea en blanco antes, mientras que las dos etiquetas de ruptura le dicen al navegador que avance hasta la siguiente línea sin dejar líneas en blanco en medio. Aunque el navegador da un bonito formato al documento, la máquina aún no sabe que se trata de una dirección postal.

Procesamiento de HTML

Para continuar la discusión con el ejemplo del documento HTML, consideremos la tarea de extraer el código postal de la dirección. Aquí presentamos un (intencionadamente frágil) algoritmo para encontrar la marca HTML para el código postal: Si se encuentra un párrafo con dos etiquetas <br>, el código postal es la segunda palabra después de la primera coma en la segunda etiqueta de ruptura. Aunque este algoritmo funciona con el ejemplo, existen en el mundo una gran cantidad de direcciones perfectamente válidas para las cuales no puede funcionar. Incluso si se pudiera escribir un algoritmo que encontrase el código postal para cualquier dirección escrita en HTML, existe un gran número de párrafos con dos etiquetas de ruptura cuyo contenido no es una dirección postal. La escritura de un algoritmo que busque en cualquier párrafo HTML y encuentre cualquier código postal que contenga sería extremadamente difícil, sino imposible.

Echemos un vistazo ahora a un documento XML de ejemplo. Con XML, se puede asignar algún significado a las etiquetas en el documento. Más importante aún, también resulta fácil para una maquina el procesar la información. Se puede extraer el código postal de un documento simplemente localizando el contenido rodeado por las etiquetas <codigo-postal> y </codigo-postal>, técnicamente conocido como el elemento <codigo-postal>.

<direccion> <nombre> <titulo>Mrs.</titulo> <nombre> Mary </nombre> <apellidos>McGoon </apellidos> </nombre> <calle> 1401 Main Street </calle> <ciudad>Anytown</ciudad> <estado>NC</estado> <codigo-postal> 34829 </codigo-postal> </direccion>

Etiquetas, elementos y atributos

Existen tres términos comúnmente usados para describir las partes de un documento XML: etiquetas, elementos y atributos. Aquí está un documento de ejemplo que ilustra estos términos:

<direccion> <nombre> <titulo>Mrs.</titulo> <nombre> Mary </nombre> <apellidos> McGoon </apellidos> </nombre> <calle> 1401 Main Street </calle> <ciudad estado="NC">Anytown</ciudad> <codigo-postal> 34829 </codigo-postal> </direccion>

Una etiqueta es un texto entre el símbolo menor que (<) y el símbolo mayor que (>). Existen etiquetas de inicio (como <nombre>) y etiquetas de fin (como </nombre>). Un elemento consta de la etiqueta de inicio, la etiqueta de fin y de todo aquello que este entre ambas. En el ejemplo anterior, el elemento <nombre> contiene tres elementos hijos: <titulo>, <nombre>, y <apellidos>. Un atributo es un par nombre-valor dentro de la etiqueta de inicio de un elemento. En este ejemplo, estado es un atributo del elemento <ciudad>, en ejemplos anteriores <estado> era un elemento.

Cómo está cambiando XML la Web

Ahora que ha visto como los desarrolladores pueden usar XML para crear documentos con datos que se auto-describen, veamos cómo se están usando esos documentos para aumentar el rendimiento de la Web. Aquí mostramos algunas áreas:

XML simplifica el intercambio de datos. Debido a que diferentes organizaciones ( en incluso diferentes partes dentro de una misma organización) raramente utilizan un único conjunto de herramientas, esto puede suponer una cantidad de trabajo significativa para comunicar las aplicaciones. Usando XML cada grupo crea una única utilidad que transforma sus formatos de datos internos en XML y viceversa. Lo mejor de todo, hay una gran probabilidad de que sus suministradores de software, ya proporcionen herramientas que transformen sus registros de base de datos( o directorios LDAP, o ordenes de compra, etc.) desde y hacia XML. XML permite un código más ligero. Debido a que los documentos XML pueden ser estructurados para identificar cada pieza importante de información ( así como las relaciones entre dichas piezas), es posible escribir código que procese estos documentos XML sin intervención humana. El hecho de que los proveedores de software hayan gastado cantidades masivas de tiempo y dinero construyendo herramientas de desarrollo XML significa que escribir ese código es un proceso relativamente simple. XML permite búsquedas más rápidas. Aunque los motores de búsqueda han mejorado sustancialmente durante los años, es todavía bastante común encontrar resultados erróneos en una búsqueda. Si se están buscando páginas HTML de alguien llamado "Chip", se pueden encontrar páginas sobre chips de chocolate, chips de ordenador, chips de madera y montones de otros enlaces inútiles. Buscando en documentos XML por elementos <nombre> que contengan el texto Chip debería darnos un conjunto de resultados mucho mejor.

Sección 3. Reglas de los documentos XML. Visión General

Si ha visto los documentos XML, estará familiarizado con los conceptos básicos del uso de etiquetas para marcar el texto de un documento. Esta sección discute las diferencias entre los documentos XML y los documentos XML. Va más allá de las reglas básicas de los documentos XML y discute la terminología usada para describirlos. Un punto importante acerca de los documentos XML: La especificación XML requiere un parser para rechazar los documentos XML que no sigan las reglas básicas. Muchos analizadores HTML aceptarán marcados chapuceros haciendo conjeturas sobre lo que el escritor del documento intentaba. Para evitar el revoltijo de estructuras encontrado en la mayoría de los documentos HTML, los creadores de XML decidieron reforzar la estructura del documento desde el principio. (De hecho, si usted no está familiarizado con el termino, un parser es una pieza de código que intenta leer un documento e interpretar su contenido.)

Documentos inválidos, válidos y bien formados

Hay tres tipos de documentos XML:

Documentos inválidos no siguen las reglas de sintaxis definidas por la especificación XML. Si un desarrollador tiene reglas definidas de lo que ese documento puede contener en una DTD o Esquema, y el documento no las sigue, ese documento es inválido. (Ver Definiendo el contenido del documento en la página 13 para una introducción apropiada a los DTDs y Esquemas de los documentos XML.) Documentos válidos siguen tanto las reglas de sintaxis XML como las reglas definidas en su propio DTD o Esquema. Documento bien formado sigue las reglas de sintaxis XML, pero no tiene un Esquema o DTD.

El elemento raíz
Un documento XML debe estar contenido en un elemento único. Este elemento único es llamado el elemento raíz y contiene todo el texto y cualquier otro elemento en el documento. En el ejemplo siguiente, el documento XML está contenido en un elemento único, el elemento <greeting>. Notese que el documento tiene un comentario el cual, aunque está fuera del elemento raíz, es perfectamente legal

<?xml version="1.0"?> <!--Un documento bién formado-->
<saludo> ¡Hola Mundo! </saludo>

Aquí presentamos un documento que no contiene un único elemento raíz:

<?xml version="1.0"?> <!--Un documento no válido --> <saludo> ¡Hola Mundo! </saludo> <saludo> ¡Hola, el Mundo! </saludo>

Es necesario un parser XML para rechazar el documento, independientemente de la información que pueda contener.

Los elementos no pueden solaparse

Los elementos XML no pueden solaparse. Aquí presentamos un marcado ilegal:

<!--marcado XML ilegal --> <p> <b>Yo <i>amo de verdad </b> XML. </i>

Si comienza un elemento <i> dentro de un elemento <b> también deberá terminarlo dentro. Si se quiere que el texto XML aparezca en cursiva, hay que añadir un segundo elemento <i> para corregir el marcado:

<!--marcado XML legal --> <p> <b>Yo <i>amo de verdad </i> </b> <i>XML. </i>

Un parser XML aceptará solamente este marcado; Los parser HTML de la mayoría de los navegadores aceptarán ambos.

Las etiquetas de fin son obligatorias

No puede olvidarse de ninguna etiqueta de fin. En el primer ejemplo que sigue, el marcado no es legal debido a que no hay etiquetas de fin de párrafo (

<!--Marcado XML NO LEGAL --> <p>Yada yada yada...

<p>Yada yada yada... <p>...

Si un elemento carece de contenido se le llama elemento vacío; los elementos HTML para ruptura (<br>) e imagen (<img>) son dos ejemplos. En los elementos vacíos en XML pueden ponerse lo barra de cierre en la etiqueta de inicio. Los dos elementos de ruptura y los dos elementos de imagen a continuación significan la misma cosa para un parser XML:

<!-- Dos rupturas equivalentes --> <br></br> <br/> <!-- Dos elementos de imagen equivalentes --> <img src="/img/c.gif"></img> <img src="/img/c.gif" />

Los elementos son sensibles a mayúsculas

Los elementos XML son sensibles a mayúsculas. En HTML, <h1> y <H1> son lo mismo; en XML no. Si intenta terminar un elemento <h1> con una etiqueta </H1>, obtendrá un error. En el ejemplo siguiente, el primero presenta un encabezado ilegal, mientras que el último es correcto.

<!-- marcado XML ILEGAL --> <h1>Los elementos son sensibles a mayusculas</H1> <!-- marcado XML LEGAL --> <h1> Los elementos son sensibles a mayusculas</h1>

Los atributos deben tener valores entrecomillados

Existen un par de reglas para los atributos en los documentos XML: · · Los atributos deben tener valores Esos valores deben estar entrecomillados.

Compare los dos ejemplos que vienen a continuación. El marcado del primero es legal en HTML, pero no en XML. Para obtener el equivalente en XML, se le debe dar un valor al atributo y debe entrecomillarse.

<!-- marcado XML ILEGAL --> <ol compact> <!-- marcado XML LEGAL --> <ol compact="yes">

Puede usar comillas simples o dobles siempre y cuando sea consecuente. Si el valor del atributo contiene un single o un double puede usarse el otro tipo de comillas para rodear el valor ( como en nombre="Doug's car"), o usar las entidades " para comillas dobles y ' para comillas simples. Una entidad es un símbolo, como ", que el parser XML reemplazará con otro texto como ".

Declaraciones XML

Muchos documentos XML comienzan con una declaración XML que proporciona al parser información básica sobre el documento. Una declaración XML está recomendada, pero no es obligatoria. Si existe una, debe ser lo primero que aparezca en el documento. La declaración puede contener hasta tres pares nombre-valor (mucha gente les llama atributos, aunque técnicamente no lo son). version es la versión de XML usada; actualmente este valor debe ser 1.0. encoding es el conjunto de caracteres usado en el documento. El conjunto de caracteres ISO-8859-1 referenciado en esta declaración incluye todos los caracteres usados en la mayoría de los lenguajes de Europa Occidental. Si no se especifica encoding el parser XML asume que los caracteres pertenecen al conjunto UTF-8, un estándar Unicode que soporta virtualmente cada carácter e ideograma de cualquier lenguaje del mundo.

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

Finalmente, standalone, que solo puede ser yes o no, define si este documento puede ser procesado sin leer otros ficheros. Por ejemplo, si el documento XML no referencia ningún otro fichero, puede especificarse standalone="yes". Si el documento XML referencia otros ficheros que describen lo que el documento puede contener (veremos más acerca de estos ficheros en un momento), se debe especificar standalone="no". Debido a que standalone="no" es la opción por defecto, raramente veremos standalone en las declaraciones XML.

Otras cosas en los documentos XML

Hay algunas otras cosas que se pueden encontrar en un documento XML:

Comentarios: los comentarios pueden aparecer en cualquier lugar en el documento; incluso antes o después del elemento raíz. Un comentario comienza con <!--y termina con -->. Un comentario no puede contener un guión doble (--), excepto al final; con esta excepción, un comentario puede contener cualquier cosa. Aún más importante, cualquier marca dentro de un comentario será ignorada; si quiere eliminar una gran sección de un documento XML simplemente introdúzcala en un comentario. (Para restaurar la sección comentada simplemente elimine las etiquetas de comentario.) Aquí presentamos un ejemplo que contiene un comentario.

<!--Esto es una PI para Cocoon: --> <?cocoon-process type="sql"?>

Instrucciones de procesamiento: Una instrucción de procesamiento es una marca que se interpretará como un segmento de código. En el ejemplo previo hay una instrucción de procesamiento ( algunas veces llamadas PI) para Cocoon, un marco de procesado para XML de Apache Software Foundation. Cuando Cocoon está procesando un documento XML busca instrucciones de procesamiento que comiencen con cocoon-process, entonces procesa el documento XML de acuerdo a ellas. En este ejemplo, el atributo type="sql" le dice a Cocoon que el documento XML contiene una sentencia SQL.

<!-- He aquí una entidad: --> <!ENTITY dw "developerWorks">

Entidades: El ejemplo previo define una entidad para el documento. Dondequiera que el procesador XML encuentre la cadena &dw;, la reemplazará con la cadena developerWorks. La especificación XML también define cinco entidades que pueden usarse en lugar de varios caracteres especiales. Las entidades son: · < para el símbolo menor que (<) · > para el símbolo mayor que (>) · " para las comillas dobles (") · ' para la comilla simple o apostrofe (`) · & para el ampersand (&).

Namespaces

El poder de XML proviene de su flexibilidad, del hecho de que usted, yo y millones de otras personas podamos definir nuestras propias etiquetas para describir nuestros datos. ¿Recuerda el ejemplo del documento XML con el nombre y dirección de una persona? Ese documento incluía el elemento <titulo> para el título o tratamiento de cortesía, una elección perfectamente razonable como nombre de un elemento. Si usted crea una librería online, podría elegir el crear un elemento <titulo> para almacenar el título de un libro. Si crea una compañía hipotecaria online, podría elegir crear un elemento <titulo> Para el título de una propiedad. Todas son elecciones razonables, pero todas ellas crean elementos con el mismo nombre. ¿Cómo saber si, dado un elemento <titulo> se refiere a una persona, un libro o una propiedad? Con los namespaces.

Para usar un namespace, debe definir un prefijo namespace y mapearlo a una cadena particular. Así es cómo se deberían definir prefijos namespace para nuestros tres elementos <titulo>:

<?xml version="1.0"?> <resumen_usuario xmlns:direccion="http://www.xyz.com/direcciones/" xmlns:libros="http://www.zyx.com/libros/" xmlns:hipoteca="http://www.yyz.com/hipotecas/" > ... <direccion:nombre> <titulo>Mrs.</titulo> ... </direccion:nombre> ... ... <libros:titulo>El Señor de los Anillos</libros:titulo> ... ... <hipoteca:titulo>NC2948-388-1983 </hipoteca:titulo>

En este ejemplo, los tres prefijos del namespace son direccion, libros e hipoteca.

Dese cuenta que la definición de un namespace para un elemento particular significa que todos los elementos hijos pertenecen al mismo namespace. El primer elemento <titulo> pertenece al namespace direccion debido a que su elemento padre <direccion:Nombre>, ya pertenecía a ese namespace. El punto final: La cadena de una definición de namespace es solo una cadena. Si, esa cadena parece una URL, pero no lo es. Podría definir xmlns:direccion="mike" y funcionaría exactamente igual, Lo único que importa acerca de la cadena del namespace es que sea única; por esto la mayor parte de las definiciones de namespace parecen URLs. Los parser XML no van a la dirección http://www.zyx.com/libros/ para buscar una DTD o un Esquema, simplemente usan esos textos como cadenas. Es confuso, pero así es como funcionan los namespaces.

Sección 4. Definición del contenido de un documento Visión General

Durante este tutorial ha estado aprendiendo acerca de las reglas básicas de los documentos XML; eso está bien, pero ahora necesita definir los elementos que usará para representar datos. Aprenderá dos maneras de hacerlo en esta sección:

Un método es usar un Document Type Definition o DTD. Un DTD define los elementos que pueden aparecer en un documento XML, el orden en el cual pueden aparecer, cómo pueden estar anidados y otros detalles básicos de la estructura del documento XML. Los DTD son parte de la especificación original de XML y son muy similares a los DTDs de SGML. El otro método es usar un Esquema XML (XML Schema). Un esquema puede definir todas las estructuras de documento que pudieran definirse con DTD y además, puede definir tipos de datos y reglas mucho más complicadas de las que pueden hacerse con DTD. El W3C desarrollo la especificación de Esquemas XML un par de años después que la especificación original XML.

Document Type Definitions

Un DTD permite especificar la estructura básica de un documento XML. El siguiente par de ejemplos muestra lo que aparece cómo fragmentos de DTDs. El primero de ellos es una DTD que define la estructura básica del documento de ejemplo que vimos más arriba:

<!-- direccion.dtd --> <!ELEMENT direccion (nombre, calle, ciudad, estado, codigo-postal)> <!ELEMENT nombre (titulo? nombre, apellidos)> <!ELEMENT titulo (#PCDATA)> <!ELEMENT nombre (#PCDATA)> <!ELEMENT apellidos (#PCDATA)> <!ELEMENT calle (#PCDATA)> <!ELEMENT ciudad (#PCDATA)> <!ELEMENT estado (#PCDATA)> <!ELEMENT codigo-postal (#PCDATA)>

Este DTD define todos los elementos usados en el documento de ejemplo. Define tres cosas básicas:

Un elemento <direccion> que contiene un <nombre>, un <calle>, un <ciudad>, un <estado>, y un <codigo-postal>. Todos estos elementos deben aparecer y deben hacerlo en ese mismo orden.

Un elemento <nombre> contiene un elemento <titulo> opcional (la marca de pregunta indica que titulo es opcional), seguido de un elemento <nombre> y de un elemento <apellidos>.

Todos los demás elementos contienen texto. (#PCDATA indica datos de carácter; no pueden incluirse otros elementos dentro de estos.) Aunque son muy simples, las DTD aclaran que combinaciones de elementos son legales. Una documento de dirección postal que presente un elemento <codigo-postal> antes de un elemento <estado> no es legal, y ningún documento que no presente el elemento <apellidos> lo será. Además, hay que darse cuenta de que la sintaxis DTD es diferente de la sintaxis XML ordinaria. (Los documentos de Esquema XML, por el contrario, son XML ellos mismos, lo cual tiene algunas consecuencias interesantes.) A pesar de la sintaxis diferente de los DTDs se pueden seguir insertando comentarios ordinarios dentro de ellas.

Símbolos en los DTDs

Existen unos pocos símbolos usados en los DTDs para indicar cuantas veces (si es que lo hace) algo puede aparecer en un documento XML. Aquí mostramos algunos ejemplos junto a sus significados:

<!ELEMENT direccion (nombre, ciudad, estado)>

El elemento <direccion> debe contener un elemento <nombre>, un <ciudad>, y un <estado> en ese orden. Todos los elementos son obligatorios. La coma indica una lista de items.

<!ELEMENT nombre (titulo?, nombre, apellidos)>

Esto significa que el elemento <nombre> contiene un elemento <titulo> opcional, seguido obligatoriamente de un elemento <nombre> y de otro <apellidos>. La marca interrogación, indica que un item es opcional; Puede o no aparecer.

<!ELEMENT agenda (direccion+)>

Un elemento <agenda> contiene uno o más elementos <direccion>. Se pueden tener tantos elementos <direccion> como se necesiten, pero, al menos, debe existir uno. El signo mas (+) indica que un item debe aparecer al menos una vez, pero puede aparecer cualquier número de veces.

<!ELEMENT direcciones-privadas (direccion*)>

Un elemento <direcciones-privadas> contiene cero o más elementos <direccion>.

El asterisco indica que un item puede aparecer cualquier número de veces, incluyendo cero.

<!ELEMENT nombre (titulo?, nombre, (inicial-segundo-nombre | segundo-nombre)?, apellidos)>

Un elemento <nombre> contiene un elemento <titulo> opcional seguido de un elemento <nombre>, posiblemente seguido de un <inicial-segundo-nombre> o un elemento <segundo-nombre>, seguido de un elemento <apellidos>. En otras palabras, tanto <inicial-segundo-nombre> como <segundo-nombre> son opcionales y solamente se puede tener uno de los dos. Las barras verticales indican una lista de opciones; solo se puede escoger un item de la lista. Hay que notar que en este ejemplo se han usado paréntesis para agrupar ciertos elementos, y una marca de interrogación que afecta a todo el grupo.

<!ELEMENT nombre ((titulo?, nombre, apellidos) | (apellido, nombre-madre, apodo))> El elemento <nombre> puede contener una o más secuencias: Un elemento <titulo> opcional, seguido de un elemento <nombre> y otro <apellidos>; o un <apellido>, un <nombre-madre>, y un <apodo>.

Una palabra acerca de la flexibilidad

Antes de seguir, introduciremos una breve nota acerca del diseño de DTDs de cara a la flexibilidad. Considerando el ejemplo de dirección postal; lo hemos escrito claramente con la codificación postal de Estados Unidos en la mente. Si se quiere un DTD o esquema que defina reglas para otros tipos de direcciones, debería de añadir mucha más complejidad. El requerir un elemento <estado> puede tener sentido en Australia, pero no lo tendrá en Reino Unido. Una dirección canadiense podría ser manejada por el DTD de ejemplo de Document Type Definitions en la página 13, pero añadir un elemento <provincia> parece una idea mejor. Finalmente, hay que tener en cuenta que en muchos lugares del mundo, conceptos tales como título, primer nombre y segundo nombre no tienen sentido. Como punto final: si esta definiendo la estructura de un documento XML, debería ser tan prevenido en su DTD o esquema como si estuviese diseñando el esquema de la base de datos o la estructura de datos en una aplicación. Cuanto más requerimientos de futuro pueda prevenir, tanto más fácil y más barato le será el implementarlos más tarde.

Definición de atributos

Este tutorial introductorio no puede profundizar demasiado en cómo trabajan los DTDS, pero hay un tópico básico que sí cubriremos aquí: la definición de atributos. Se pueden definir atributos para los elementos que aparecen en su documento XML. Usando una DTD también se puede:

Definir qué atributos son obligatorios. Definir valores por defecto para los atributos Proporcionar una lista con los valores válidos para un atributo.

Supongamos que se quiere cambiar la DTD para hacer que estado sea un atributo del elemento <ciudad>. Se haría así:

<!ELEMENT ciudad (#PCDATA)> <!ATTLIST ciudad estado CDATA #REQUIRED>

Esto define el elemento <ciudad> como antes, pero el ejemplo revisado también usa una declaración ATTLIST para enumerar los atributos del elemento. El nombre ciudad dentro de la enumeración de atributos le dice al parser que esos atributos están definidos para el elemento <ciudad>. El nombre estado es el nombre del atributo y las palabras reservadas CDATA y #REQUIRED le dicen al parser que el atributo estado contiene texto y es obligatorio ( si fuese opcional, se indicaría con CDATA #IMPLIED). Para definir múltiples atributos para un elemento, se escribe un ATTLIST como este:

<!ELEMENT ciudad (#PCDATA)> <!ATTLIST ciudad estado CDATA #REQUIRED codigo-postal CDATA #REQUIRED>

Este ejemplo define estado y codigo-postal como atributos del elemento <ciudad>. Finalmente, las DTDS permiten definir valores por defecto para los atributos y enumerar los valores válidos para un atributo: <!ELEMENT ciudad (#PCDATA)> <!ATTLIST ciudad estado CDATA (AZ|CA|NV|OR|UT|WA) "CA">

Este ejemplo indica que solo se soportan direcciones de los estados de Arizona (AZ), California (CA), Nevada (NV), Oregon (OR), Utah (UT), y Washington (WA), y que el valor por defecto es California. De esta manera se puede realizar una muy limitada forma de validación de los datos. Aunque es una función útil, es solo una pequeña parte de lo que se puede hacer con los esquemas XML.

Esquemas XML

Con los esquemas XML se tiene un mayor poder para definir lo que parece un documento XML válido. Presentan varias ventajas sobre los DTDs:

Los esquemas usan sintaxis XML. En otras palabras, un esquema XML es un documento XML. Esto significa que se puede procesar un esquema igual que cualquier otro documento. Por ejemplo, se puede escribir una hoja de estilo XSLT que convierta un esquema XML en un formulario Web completo con código JavaScript generado automáticamente que valide los datos conforme se vayan introduciendo.

Los esquemas XML soportan tipos de datos. Mientras que los DTDs no soportan tipos de datos, esta claro que esos tipos de datos fueron desarrollados con una perspectiva de publicación. Los esquemas XML soportan todos los tipos originales de los DTDs (cosas como Ids y referencias ID). También soportan enteros, números en punto flotante, fechas, horas, cadenas de texto, URLs y otros tipos de datos útiles para el procesado y validación de datos. Los esquemas XML son extensibles. Además de los tipos de datos definidos en la especificación de esquemas XML, se pueden crear tipos de datos propios y se pueden derivar nuevos tipos de datos a partir de otros. Los esquemas XML tienen mayor poder de expresión. Por ejemplo, con esquemas XML se puede definir que el valor del un atributo <estado> no puede tener una longitud mayor de 2 caracteres, o que el valor de un elemento <codigo-postal> debe cumplir la expresión regular [0-9]{5}(-[0-9]{4})?. No se puede hacer ninguna de estas cosas con los DTDs.

Un esquema XML de ejemplo

A continuación presentamos un esquema XML que coincide con nuestra DTD original de nombre y dirección postal. Añado dos restricciones: el valor del elemento <estado> debe tener exactamente dos caracteres de longitud y el valor del elemento <codigo-postal> debe cumplir con la expresión regular [0-9]{5}(-[0-9]{4})?. Aunque el esquema es mucho mayor que la DTD, expresa de manera más clara qué documentos serán válidos. Este es el esquema:

<?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="direccion"> <xsd:complexType> <xsd:sequence> <xsd:element ref="nombre"/> <xsd:element ref="calle"/> <xsd:element ref="ciudad"/> <xsd:element ref="estado"/> <xsd:element ref="codigo-postal"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="nombre"> <xsd:complexType> <xsd:sequence> <xsd:element ref="titulo" minOccurs="0"/> <xsd:element ref="nombre"/> <xsd:element ref="apellidos"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element type="xsd:string"/> name="titulo" name ="nombre" type="xsd:string"/> name ="apellidos" type="xsd:string"/> name ="calle" type="xsd:string"/> name ="ciudad" type="xsd:string"/> <xsd:element name ="estado"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:length value="2"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name ="codigo-postal"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:pattern value="[0-9]{5}(-[0-9]{4})?"/> </xsd:restriction> </xsd:simpleType> </xsd:element> </xsd:schema>

Definición de elementos en los esquemas

El esquema XML presentado en Un esquema XML de ejemplo en la página 17, define varios elementos XML con el elemento <xsd:element>. Los primeros dos elementos definidos,<direccion> y <nombre>, estan compuestos por otros elementos. El elemento <xsd:sequence> define la secuencia de elementos contenidos en cada uno de ellos. A continuación mostramos un ejemplo:

<xsd:element name="direccion"> <xsd:complexType> <xsd:sequence> <xsd:element <xsd:element <xsd:element <xsd:element <xsd:element </xsd:sequence> </xsd:complexType> </xsd:element> ref="nombre"/> ref="calle"/> ref="ciudad"/> ref="estado"/> ref="codigo-postal"/>

Como en la versión DTD, el esquema XML de ejemplo define que <direccion> contiene un elemento <nombre>, un <calle>, un <ciudad>, un <estado>, y un <codigo-postal>, en ese orden. Se debe notar que el esquema define un nuevo tipo de datos con el elemento <xsd:complexType>. Definir la mayor parte de los elementos que contienen texto es sencillo. Unicamente se declara el nuevo elemento y se le da un tipo de datos xsd:string:

<xsd:element <xsd:element <xsd:element <xsd:element <xsd:element name="titulo" type="xsd:string"/> name="nombre" type="xsd:string"/> name="apellidos" type="xsd:string"/> name="calle" type="xsd:string"/> name="ciudad" type="xsd:string"/>

Definición del contenido de los elementos en los esquemas

El esquema de ejemplo define restricciones para el contenido de dos elementos: el contenido del elemento <estado> debe tener una longitud de dos caracteres, y el contenido de un elemento <codigo-postal> debe cumplir la expresión regular [0-9]{5}(-[0-9]{4})?. Así es como se hace:

<xsd:element name="estado"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:length value="2"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="codigo-postal"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:pattern value="[0-9]{5}(-[0-9]{4})?"/> </xsd:restriction> </xsd:simpleType> </xsd:element>

Para los elementos <estado> y <codigo-postal>, el esquema define nuevos tipos de datos con restricciones. En el primer caso usa el elemento <xsd:length> y en el segundo usa <xsd:pattern> para definir una expresión regular que ese elemento debe cumplir. Este resumen solo araña la superficie de lo que los esquemas XML pueden hacer; hay libros enteros dedicados a este asunto. Para el propósito de esta introducción basta con decir que los esquemas XML son una manera muy potente y flexible de describir lo que un documento XML debe parecer.

Última actualización: 2007-04-29 10:56:59-05