CURSO DE XML

Captulo 1 XML en la evolucin de la Web _ ____2

Captulo 2 Tecnologas y conceptos previos al XML_______24
Captulo 3 Escribir Documentos XML _________________42
Captulo 4 Esquemas_______________________________66
Captulo 5 Tecnologas de localizacin xPath ____95
Captulo 6 Tecnologas para enlazar documentos XML_____121
Captulo 7 Consultas en XML: XQuery_________________ 140
Captulo 8 Transformacin de documentos: XSLT_ _______165
Captulo 9 Interaccin y manejo de documentos XML: DOM_189

1
1 CAPTULO
XML en la evolucin de la Web

La World Wide Web (que designaremos la Web) surgi en el seno de la cultura
informtica de los sistemas distribuidos, esto es, asumiendo que la informacin
que se necesita no reside en un nico computador central, sino que se encuentra
repartida en diversos computadores cuya direccin incluso puede desconocerse.
Aunque internet empez a desarrollarse en los aos 60, la Web no apareci hasta
1990, cuando Tim Berners-Lee, que trabajaba como tcnico informtico en el CERN
(Centre dEtudes de Recherche Nucleaire) de Ginebra empez a desarrollar una
tecnologa, basada en un sistema cliente/servidor, destinada a poder compartir
informacin basada en documentos que incorporasen tanto la caracterstica de
hierte!to (un texto con enlaces a otros documentos o partes de documentos de
tal forma que seleccionando estos enlaces, con ratn o teclado, se puede acceder a
otro documento que a su vez puede ser asimismo hipertextual, gracias a lo cual se
construye una trama para obtener informacin a medida que se refiera) como de
hiermedia (el contenido no es necesariamente un texto, sino que puede venir
dado a travs de otros medios como sonido, imgenes, videos, o incluso programas
susceptibles de ser ejecutados).
Entre estos aspectos bsicos de la Web, Tim especific el lenguaje de marcado de
documentos "TML (HiperText Markup language), y cuando sta ya era el sistema
clientes/servidoras extendido del mundo, en 1994 con el soporte de Michael
Dertouzos, entonces responsable del Laboratorio de Ciencias de la Computacin del
Instituto Tecnolgico de Massachussets, fund el World Wide Web Consortium
(W3C), donde sigue trabajando como director. La misin del W3C es por un lado
1.1. Datos semiestructurados, documentos, recursos y agentes en la Web
1.2. La arquitectura Web y su evolucin
1.3. El marcado de la Web
1.4. Documentos XML
1.5. La familia XML en la nueva Web
1.5. La familia XML en la nueva Web
2
guiar el uso y ampliacin de la Web para obtener su mximo potencial mediante una
serie de Recomendaciones consensuadas por la comunidad internacional, y por otro
asegurar su estabilidad y el acceso universal a ella. En consecuencia cada vez que a
lo largo del presente texto se haga referencia a una Recomendacin W3C hay que
asumir que sin ser un estndar oficial, s es un estndar "de facto. Ello significa que
es un documento aceptado por la prctica totalidad de los colectivos que utilizan
XML (varias docenas de millares en todo el mundo) y que en su elaboracin han
participado los actores profesionales y acadmicos mas solventes, y se han
alcanzado un consenso prcticamente universal, despus de segui un proceso
especialmente meticuloso y respetuoso con todas las opciones.
1#1# $atos semiestructurados% documentos% recursos & a'entes de la Web
La aparicin de la Web renov uno de lo problemas constantes desde los primeros
pasos de la informtica: la posibilidad de compartir informacin de la eficiente. Este
es un tema presente desde los inicios de la programacin, que siempre ha intentado
facilitar la forma de transmitir datos desde un segmento de cdigo a otro, cosa que
supone programar de forma estandarizada, aun a costa de la claridad y brillantez del
cdigo. En la evolucin del Software (cdigo fuente lineal, funciones y subrutinas,
clases en orientacin a objetos, procesamiento distribuido, programacin por
componentes, desarrollo colaborativo, etc.) se observa que siempre ha existido el
reto de coordinar correctamente la distribucin de datos, de forma que los mtodos
para ellos han evolucionado con las tecnologas disponibles en cada momento:
localizaciones fijas o en memoria, registros o entidades "snack, variables globales,
variables locales, estructuras y punteros, lenguajes basados en objetos. y as hasta
llegar a XML, el objetivo de este texto.
El paradigma perseguido para la Web consiste en contar con mecanismos que
hagan que conjuntos de datos no homogneos residentes de distintos lugares
trabajen como si estuvieran organizados de forma homognea, lo que se conoce
como inte'racin de la in(ormacin# Para enfrentar esta integracin, en principio
existen dos tipos de soluciones:
A) el llamado "warehousing, consistente en hacer copia de las fuentes de datos
en un lugar centralizado para transformarlos a un esquema comn para todos,
lo que supone reconstruir los datos cada cierto periodo de tiempo (diario,
semanal, etc.) tratando que stos se mantengan razonablemente actualizados
en funcin de cada necesidad;
B) crear una forma de presentar los dato de modo que aparezcan como si
verdaderamente estuvieran integrados, esto es, conseguir un sistema que
traduzca cada consulta a la terminologa
3
La primera opcin pareca inabordable en un sistema de informacin de la
dimensin de la Web, hasta que empezaron a surgir soluciones en esta lnea, dando
lugar a fenmenos como Google, donde sin ser un "warehousing tradicional se
consiguen soluciones ms que interesantes. En la lnea de la segunda solucin,
pronto se concluy que se necesitaba un nuevo modelo de datos, llamado datos
semiestructurados, cuyo objetivo es representar datos procedentes de fuentes
distintas de una forma ms flexible que como lo hacen los modelos relacionados u
orientados a objetos. Ello supone considerar el tipo de objeto, no tanto como
perteneciente a una clase, sino ms bien ubicado en el entorno en el que va a ser
explotado. Para conseguirlo aparece la necesidad de etiquetar de alguna manera la
informacin para poder indicar el significado de cada una subestructura y a partir de
ello proceder a su integracin en cada aplicacin. De forma ms concreta se definen
datos semiestructurados a una clase de grafos etiquetados, cuyos nodos son
objetos y cuyas etiquetas asociadas a sus arcos indican bien los atributos del objeto,
bien las relaciones existentes entre los objetos. Como se observa, ello supone una
descomposicin sucesiva de los datos hasta llegar a los nodos hojas que son valores
atmicos.
La flexibilidad, que facilita la integracin de la informacin perseguida, se obtiene
por el hecho de que en el modelo de datos semiestructurados coexiste restriccin
alguna, ni sobre el nmero de etiquetas que salgan de un nodo, ni de la cantidad de
sucesos que pueda presentar una etiqueta dada.
Es en el marco de esta evolucin para poder compartir datos donde hay que ubicar
XML (Extensible Markup Language), cuyas caractersticas podemos adelantar: un
lenguaje de marcas (realmente un metalenguaje) con un formato consistente, que
permite intercambiar dato por medio de cualquier programa, en no importa qu
lenguaje ni qu plataforma, utilizando etiquetas que tiene un sentido semntico (ello
permite expresar cosas como "esto es una direccin). La idea para explotar los
grafos que soportan datos semiestructurados reside en crear conjuntos de etiquetas
para un dominio concreto (genmica, temas financieros, etc.), de forma que se
pueda traducir adecuadamente los datos correspondientes a documentos
correctamente etiquetados. En consecuencia hay que considerar al XML como un
metalenguaje estndar para representar y describir datos semiestructurados.
Se llama documento a cualquier dato que pueda presentarse en forma digital,
una definicin que engloba desde una mnima unidad de informacin hasta un
conjunto de unidades ms o menos estructuradas, como pide el concepto de datos
semiestructurados. Se entiende por contenido de un documento al conjunto de
textos, imgenes, videos, etc., incluidos en l. Puesto que en un sistema distribuido,
un documento, puede almacenarse tanto en un archivo nico, como estar dividido
en varios, se distingue en l una estructura ()sica compuesta por unidades de
almacenamiento llamadas entidades (una o varias) con su contenido respectivo, y
4
una estructura l'ica compuesta de declaraciones de elementos, referencias, etc.,
que le dan la unidad necesaria desde el punto de vista de pieza de informacin. Por
ello, todo documento tiene asociado una entidad del documento que sirve como
raz o inicio para accederlos, de tal manera que una entidad pueda referirse a otras
entidades para dar lugar a su inclusin el documento, lo que supone poder manejar,
sin ningn problema aadido, los correspondientes archivos asociados a la entidad
inicial.
Considerada como un espacio de informacin, la Web permita localizar y acceder a
recursos, entendiendo como tales cualquier cosa que pueda ser nombrada o
descrita, lo que supone que los recursos no tienen por qu ser necesariamente
accesibles va internet e incluso que conceptos abstractos (como por ejemplo
"autor) puedan ser recursos. A pesar de la generalidad que hemos asignado al
concepto de recursos, lo ms habitual es que stos adopten la forma de documento
dentro de internet y por ello, para su descripcin e identificacin se utilizan los
llamados M*M+ (Multiproposal Internet Mail Extensions), que entre otras cosas,
definen contenidos y mecanismos para su acceso usando una nomenclatura basada
en el tipo (por ejemplo: "text, "application, etc.) y un subtipo (por ejemplo:
"html, "xml).
Dentro de la Web, se llama a'entes a las personas y/o aplicaciones software que
actan en ella accediendo a las distintas representaciones del estado de los
recursos. En particular recibe el nombre de a'ente usuario el cliente que inicia una
peticin, esto conlleva la identificacin de una solicitud a un servidor, de forma que
ste evala la informacin a proporcionar y genera un contenido adaptado a las
capacidades del usuario: los agentes de usuario adoptan la forma de navegadores,
robots, u otras herramientas de usuario final que se ejecutan en un dispositivo, de
forma que ste puede usar agentes distintos en momentos diferentes.
1#,# La ar-uitectura Web & su evolucin
La Web consta de una arquitectura con tres pilares: la identi(icacin de recursos%
que se resuelve con los URI (Uniform Resource Identifier), los rotocolos -ue
soortan la interaccin de los agentes con el espacio de informacin compartida,
resuelto con http (HiperText Transfer Protocol) y la reresentacin de
contenidos% cuyo primer formato fue HTML y que va siendo redefinido, cuando no
sustituido, por la sintaxis XML. Con el objetivo de clarificar el papel de los
componentes de esta arquitectura, consideramos la siguiente situacin:
Ana est planeando un viaje a Chile desde Mxico y en una revista lee:
Informacin meteorolica de !aldivia: http:""clima#ejemplo#com"valdivia$% su
5
experiencia le dice ste es un &'I, (ue puede darle informacin interesante para su
viaje acceder a l#
Al hacerlo se producen sucesivamente los siguientes pasos:
- Una bsqueda de los recursos identificados por el esquema de URI "http.
- El servidor "clima.ejemplo.com proporciona informacin respondiendo a la
bsqueda solicitada.
- El navegador muestra la informacin, incluyendo enlaces hipertextuales que
Ana utiliza para tener ms informacin.
Impliquemos los componentes estructurales presentes:
*denti(icacin. el recurso "condiciones meteorolgicas de Valdivia cuyo URI es
http://clima.ejemplo.com/valdivia.
Protocolo de interaccin: el navegador hace una peticin htt (/+0T
concretamente) al servidor de "clima.ejemplo.com y ste responde con un tipo
M*M+: "application/xml+xhtml.
0eresentacin. en este caso XHTML (un lenguaje que como veremos hace de
puente entre HTML y XML).
Obsrvese que el recurso "condiciones meteorolgicas consta de elementos fijos (el
lugar) y variables (la meteorologa del da), de forma que al interactuar con l se
obtiene el estado actualizado del mismo. Adems, al hacer "click sobre cualquier
hipervnculo, Ana obtendr informacin adicional en el recurso identificado por el
URI del enlace.
Esta arquitectura, con sus aciertos y debilidades, ha permitido en muy pocos aos
la sucesiva aparicin de mltiples aplicaciones. La consecuencia de este desarrollo
ha sido la aparicin de nuevos formatos de datos o de refinamiento de formatos ya
existentes y as hasta llegar a XML, que establece un formato aceptado
universalmente para almacenar, combinar, intercambiar y publicar informacin. Para
enmarcar el papel que juega XML veamos, con algo ms de detalles, la evolucin y
el papel de cada componente de la arquitectura.
1#,#1# La reresentacin en la Web
6
De forma cotidiana convivimos con el marcado o etiquetado en situaciones muy
diversas, pensemos por ejemplo en las etiquetas de identificacin de productos en
un supermercado que nos proporcionan informacin del artculo (nombre, precio,
fecha de caducidad, fabricante, etc.).
Tambin para organizar documentos, como las fotografas, se les agregan
informaciones, como la fecha y el lugar donde fue tomada, los nombres de las
personas o lugares incluidos en ellas, etc. En Informtica se entiende por un
lenguaje de marcado o ML (Markup Language): es una sintaxis de marcas o
comandos insertados en el documento, que no siendo imprescindible para la
informacin objeto del mismo, incluye nombres para los elementos que constituyen
su contenido. Por tanto con los ML se introduce la eti-ueta como un comando
insertado en el documento que especifica la forma como ste o una de sus porciones
debe organizarse, por lo que en un ML hay que especificar cosas tales como:
- Aquellas etiquetas que pueden estar presentes en los documentos.
- El orden en el que una etiqueta puede aparecer respecto de otra.
- Los atributos que pueden, o deben tener cada uno de los elementos que
determinan estas etiquetas.
- Etc.
El marcado aadido a un texto tiene el doble objetivo de, por un lado, delimitarlo
sintcticamente, y por otro de representarse estructura. Ello es posible gracias a una
doble capacidad: descritiva (organizar los documentos en parte lgicas con sus
relaciones respectivas y su contenido separado del formato) y rocedural (ayudar a
especificar el proceso a que debe someterse el documento al ser procesado).
Notemos que el mercado est presente en muchos y diferentes entornos
informticos para una amplia gama de funcionalidades:
a) Resolver problemas de presentacin, desde el tipo de letra hasta la
fotocomposicin. Por ejemplo: "*Ita Este *ROM mensaje es *Bold importante
se imprime: ")ste mensaje es imortante
b) Proporcionar el popular WYSIWYG, (siglas de "what you see what you get).
c) Estructurar archivos de texto como .csv (abreviatura inglesa de valores
separados por comas) en los que los "campos de datos se separan por comas,
utilizados habitualmente para almacenar hojas de clculo o bases de datos.
Por ejemplo: "Este es el nombre del articulo, 10234, Esta es la descripcin del
7
artculo mostrara tres campos de datos con los valores perfectamente
individualizados: )ste es el nom*re del art+culo# ,-./0# )sta es la descripcin
del art+culo#
Con lo expuesto, se explica que los ML, en forma de HTML, se pensaran como una
metodologa para enfrentar el problema de dar formato a un texto que va a
mostrarse en distintos perifricos (impresora, pantalla, telfono mvil, etc.), ya que
se proporciona la ventaja que el marcado permite distinguir entre el propio texto y
las instrucciones a seguir para proceder a su presentacin. Incluso las etiquetas
pueden dar informacin sobre el contenido, como cuando se subraya en un texto
para destacar algo ms importante que el resto. Desde sus inicios, la Web cuenta
con HTML como formato que especifica la interpretacin de la representacin de
datos y cuyo conocimiento ms o menos profundo se asume en el lector. Su uso se
ha popularizado extraordinariamente al permitir:
- Publicar documentos en lnea, especificando diferentes elementos de formato
(justificacin o alineacin de texto, color, estilo, etc.) y organizacin de la
informacin (en listas, tablas, etc.).

- Vincular o enlazar documentos o partes de ellos por medio de hipervnculos
con enlaces a documentos residentes en el propio computador o en algn
servidor remoto.
- Incluir diversos tipos de aplicaciones dentro del documento principal.
- Etc.
Sealemos que HTML se ubica en una categora intermedia entre los lenguajes de
marcado descriptivo de un lado, y los procedimentales de otro, ya que incluye tanto
etiquetas estructurales (encabezados, prrafos, citas, etc.) como etiquetas de
formato (negrita, cursiva, saltos de lnea, etc.). Hay que sealar el hecho que HTML,
con sus indiscutibles ventajas, desde su diseo inicial no tiene en cuenta el principio
de la separacin entre la representacin y la presentacin de datos, puesto que en
un documento HTML se incluyen tanto datos del contenido, como determinadas
etiquetas de formato o presentacin. A pesar de ello, es de justicia recalcar que esta
combinacin condujo a poder visualizar los documentos en la Web, dando lugar al
desarrollo inmediato de los navegadores como Netscape.
Como veremos a lo largo del texto, XML proporciona la base para enfrentar el
problema de la representacin de datos en la Web, separndolo del proceso de
presentacin de los mismos, que acaba dependiendo de las distintas posibilidades de
cada perifrico o usuario.
8
1#,#,# *denti(icacin de recursos en la Web. U0*
La posibilidad de compartir un recurso en aplicaciones distintas proporciona el
llamado "efecto red, segn el cual la utilidad de un recurso es dependiente del
tamao de la Web, y al ser la idea perseguida crear contenidos que lleguen a la
audiencia ms amplia posible (distintas mquinas, personas con incapacidades,
perifricos todava no imaginados, etc.). Resulta bsico permitir que los sistemas en
los que se distribuye la informacin puedan utilizar una gran variedad de
plataformas y formatos, que inevitablemente van a evolucionar.
Al hacerse evidente que los autores de un documento no puedan predecir la forma
como un agente mostrar o procesar el contenido que elaboran, se adopt la
decisin de explotar la capacidad de negociacin entre agentes por un lado y la
autodefinicin del contenido de cada mensaje por otro; aunque era tentador hacer
suposiciones acerca de la naturaleza del recurso basndose en su localizacin o
identificacin, se tuvo la gran intuicin de disear la Web de forma que los agentes
se intercambiaran el estado de los recursos a travs de representaciones y no de
simples identificadores. De hecho, la experiencia ha demostrado que un "html al
final de: html://ejemplo.com/pagina.html no garantiza que las representaciones de
este recurso se proporcionen con el tipo y subtipo "text/html, ya que su estado
puede evolucionar a lo largo del tiempo, y asumir que el responsable de un recurso
no va a controlar estos cambios hubiera llevado inevitablemente a un gran nmero
de enlaces rotos. Por ello, en la arquitectura elegida, se adopt desde el principio de
la independencia entre identificador y recurso, llevando a la prctica una visin
orientada a objeto.
Lo anterior pone de manifiesto que el primer problema a abordar en la Web es la
direccin y nombre de los recursos, para que una vez identificados y distinguidos,
"transmitirlos de las mas diversas maneras, y de aqu la necesidad de un marco en
el que, por un lado se pudiera definir una codificacin para nombres y direcciones de
los recursos disponibles, y que por otro las partes que se intercomunican se pongan
de acuerdo sobre el conjunto de sus identificadores y significados; ello supone
coordinar el enlace, el marcador, el indexado, etc. Siguiendo la pauta de internet,
donde las interfaces se definen en trminos de protocolos, que ha su vez determinan
la sintaxis y la semntica de los mensajes que se intercambian los agentes, en la
Web inicialmente se asoci la localizacin del recurso al protocolo que permita
accederlo. Ello dio lugar al U0L (Uniform Resource Locutor), aunque no fuera sta la
nica va para ello, ya que servicios como Gateway, Proxy o "pasarela se pueden
usar para acceder a ciertos recursos, independientemente del protocolo original e
incluso la propia resolucin de algunas URLs puede requerir el uso de ms de un
protocolo.
9
La sintaxis de los URLs proporciona un marco que permite incorporar protocolos
no considerados, o incluso no inventados todava, y como su nombre indica, localiza
recursos mediante una identificacin abstracta para luego optar sobre ellos. Otra
forma de identificar recursos es U01 (Uniform Resouce Name), que identifica
recursos persistentes independientes de su localizacin. Un URN difiere de un URL
en que su propsito principal es etiquetar persistentemente un recurso con un
identificador que se obtiene de un conjunto de espacios de nombres predefinidos,
cada uno de los cuales tiene establecida su propia estructura de nombres y
procedimientos de asignacin.
Con la expansin de la Web fue imprescindible uniformizar localizadores y
nombres, ante lo cual, la decisin fue la recalcar el papel de los identificadores; por
ello el concepto de URL del primer Web se generaliz al de URI (pasando de
"localizador a "identificador) definido como: "una cadena compacta de caracteres
(ue identifican un recurso sea f+sico o a*stracto$. Con ello un URI puede referirse a
distintos recursos:
- Accesibles por red, tal como un documento electrnico, una imagen o un
servicio.
- No accesible por red, como una seccin de libros de una biblioteca o un ser
humano ("la persona Jos Mart).
- Conceptos abstractos ("autor).
Proporcionar un URI es equivalente a asignar a una persona su nmero de
pasaporte, o a un libro su ISBN, ya que su panormica es global, es decir, el recurso
que identifica no depende del contexto en el aparece.
En principio nadie controla los URIs o su uso, y no se necesita ningn permiso
especial para crearlos, de hecho se pueden crear URIs para cosas que no nos
pertenezcan, como en el lenguaje ordinario, donde se puede asignar un nombre a
algo que no sea nuestro. Las reglas para su construccin son tan generales que se
utilizan para identificar cualquier cosa sobre la que se quiera hablar. Una vez
asignado un URI a un recurso, los agentes deben referirse a l usando el mismo URI
carcter a carcter; el agente tiene una relacin nica con la URI llamada
resonsabilidad de U0* y aunque las implicaciones sociales de esta
responsabilidad estn fuera de este texto, el xito o fracaso de su funcionamiento
reside en el consenso de la comunidad de Internet en aceptar las especificaciones
definidas.
10
Las convenciones de cada esquema de URI (por ejemplo: http, FTTP, URN, etc.)
tienen una especificacin normativa que explica cmo los identificadores se asignan
dentro de cada esquema, de forma que su sintaxis es un mecanismo de
enumeracin federado y extensible; por ejemplo: en http://clima.ejemplo.com/ el
"http que aparece antes de los dos puntos (":) nombra un esquema o plantilla URI.
Ntese que la especificacin de esta sintaxis no dice nada acerca de las propiedades
de lo nombres y direcciones a los que se aplica, y que sus propiedades salen de las
especificaciones de los protocolos; los requisitos de esta sintaxis son:
- +!tensibilidad, que se puedan agregar nuevos esquemas de nombres a
medida que se necesitan. En particular ello permite poder acceder al recurso
utilizando no importa qu protocolo existente o futuro.
- Comletitud, que sea posible codificar cualquier esquema existente.
- Caacidad de ser imreso, ya que un URI debe poder ser "trasmitido
tambin usando papel y lpiz, por lo que debe poder expresarse usando slo
caracteres ASCII.
A pesar de la libertad existente para crear URLs diferentes para un mismo recurso,
as no debe usarse: http://clima.ejemplo.com/Valdivia y
http://clima.ejemplo.com/valdivia para referirse a un nico recurso, ya que lo
agentes no detectarn la equivalencia. Lo anterior no es bice para que puedan
crearse los URIs.:
http://www.ejemplo.com/tempo y http://www.ejemplo.com/tiempo
para proporcionar acceso a usuarios que hablen italiano o espaol.
Se llama referencia URI, con un identi(icador de fragmento separado por el
carcter "#, con lo que identifica un recurso secundario respecto a uno primario,
llamado URI base, que puede referirse bien a una porcin o subconjunto de aquel,
bien a otro recurso; por tanto un URI identifica un recurso y una URIref identifica
una parte de un recurso. As en:
http://clima.ejemplo.com/valdivia
Ana puede encontrarse con la URIref:
http://clima.ejemplo.com/valdivia#manana
en informacin meteorolgica para la jornada de maana en Valdivia.
11
Se dice que un URI es relativo si es una forma abreviada de un URI absoluto, en la
que ha desaparecido algn prefijo y por tanto se requiere alguna informacin acerca
del contexto en que aparece, para poder completarlo; por ejemplo: otrapagina.html
cuando aparece en el marco del recurso: http://www.ejemplo.org/index.html
corresponde realmente al URI: http://www:ejemplo.org/otrapagina.htm
1#,#2# Protocolo en la Web. htt
Un sistema cliente /servidor trabaja como si el servidor, ubicado no importa dnde,
contuviera una gran cantidad de archivos a los que muchos usuarios quieren
acceder, de forma que esta mquina ejecuta un software que le permite estar
constantemente a la escucha para atender las demandas de los clientes, que le
mandan mensajes en un lenguaje y formato establecido y el servidor, tras localizar
lo solidaltado, lo enva al peticionario y queda a la espera de otra peticin del
mismo u otro cliente. Como ya se ha avanzado hay que enfrentarse a la posibilidad
de que el cliente pueda no entender la representacin de los datos que el servidor
tiene localizados, por estar stos en un formato desconocido para la mquina
cliente. La solucin de ello reside en aadir informacin al mensaje de respuesta,
para que el agente usuario pueda acabar utilizando esta informacin adicional para
resolver los problemas de formato.
Antes de la Web existan protocolos para servir a direcciones remotas, aunque no
acababan de cumplir sus requisitos (por ejemplo: FTP tras la transaccin sigue
conectado y el servidor controla quin pregunta y dnde sta), por lo que hubo que
aadir ciertas innovaciones hasta definir http como un protocolo orientado a objeto,
para ser usado en sistemas cooperativos con tres caractersticas bsicas:
a) La negociacin de la presentacin de datos que permite el sistema
almacenarlos independientemente de la forma en que van a ser transferidos.
b) Una vez el servidor ha cumplido con la peticin del cliente, la conexin entre
ambos cae sin que quede "memoria de las conexiones con los clientes.
c) Intercambia documentos multimedia en compatibilidad con la conexin TCP/IP
de Internet, con un paradigma peticin/respuesta donde los mensajes
correspondientes incluyen tanto la representacin de los datos pedidos, como
informacin sobre el propio recurso que se transfiere.
Por tanto un mensaje de respuesta incluye una representacin del curso
estructurada en dos partes: $atos de la reresentacin con el estado del recurso,
expresado en uno o ms formatos y Metadatos (datos respecto a datos) que
12
explican los anteriores (incluyendo el tipo MIME) con la especificacin de los
formatos usados, dando una interpretacin autorizada de la representacin.
Obviamente HTPP es complejo y heterogneo pues debe trabajar en condiciones
muy diversas (sistemas operativos, lenguajes de programacin, software, hardware,
etc.), sin embargo, a nuestros efectos, basta quedarse con la idea de que una
transaccin http consistente en una cabecera seguida opcionalmente por una lnea
en blanco y los datos del mensaje; en la cabecera se especifican cosas tales como la
accin requerida por el servidor o un cdigo de estado, de forma que el uso de estos
campos de la cabecera permiten, entre otras cosas, la autentificacin, la
encriptacin y la identificacin del usuario.
Al proporcionar una flexibilidad de la que carecen otros protocolos que no
negocian entre remitente y receptor, HTTP permite a las aplicaciones una gran
libertad tanto en el uso de tipos de datos, como en la variedad de perifricos
accesibles; todo ello gracias al bloque de metadatos que, cuando el servidor
devuelve la informacin, permiten informar sobre el tipo de datos que se envan
junto con la exacta localizacin del recurso solicitados por el cliente, de quien ya
depende el procesado apropiado de lo recibido (visualizar imgenes, videos, etc.).
Ntese que en el ocano de los documentos Web es prcticamente imposible saber
de antemano la naturaleza de un documento, y slo gracias a HTTP el usuario
"entiende los tipos de datos que maneja.
HTTP tiene un conjunto de mtodos para indicar el tipo de peticin, los ms
usados son: GET, HEAD, y POST. El mtodo GET (usado por Ana en su primer
acceso) se utiliza cuando se solicita un documento especfico bien directamente o
haciendo "click en un hipervnculo, su misin es garantizar que el acceso a un URI
no cambia el estado de sus datos. Estos cambios se pueden hacer con POST, que se
utiliza para incorporar datos desde el cliente al servidor, se trata de un mtodo
diseado para cubrir funciones tales como anotar los recursos existentes, extender
la base de datos mediante una operacin de adjuntar, etc. El mtodo HEAD se utiliza
para preguntar acerca del documento, no por el documento en s mismo,
normalmente se utiliza para comprobar que el documento no ha cambiado desde el
ltimo acceso y de ser as, la copia local del cliente puede reutilizarse sin tener que
obtenerla de nuevo con un GET, con el ahorro de recursos que ello supone.
1#2# +l mercado en la Web
Como introduccin al papel que XML juega en el desarrollo de las nuevas
posibilidades de la Web, es importante ubicar el papel de sus antecesores en el
tratamiento de los documentos con marcas.
13
1#2#1# /ML & ho3as de estilo
Los antecedentes del XML se sitan a fines de los 60, cuando un grupo de ingenieros
de IBM, ante la ya entonces gran profusin de formatos existentes, se plante
construir un sistema lo ms potente y universal posible, que permitieran
intercambiar documentos de forma automtica, es decir, obtener un formato comn
e independiente del sistema computacional. Entonces se desarroll 1M2
31enerali4ad Mar5up 2anuae6, que ms que proporcionar un formato a la
informacin contenida en un documento, buscaba marcar sus elementos
estructurales especificando su naturaleza de forma abstracta. Una aportacin de
GML, que se mantiene en su idea bsica en la actualidad, es la ho3a de estilo,
definida como un archivo separado del documento, que contiene informacin
relacionada con formatos, de forma que a partir de un conjunto de estas hojas se
puede formatear cada elemento y presentar completo un determinado documento.
Es importante recalcar que, ya entonces y mucho ms ahora, son muchas las
especificaciones que hay que pasar al perifrico correspondiente (cantidad de
espacios en blanco entre lneas de texto nmero de lneas sangradas, colores usados
para el texto, tamao de la fuente, estilo, etc.). Desde los tiempos de de GML, una
hoja de estilo es un documento declarativo, constituido por una serie de reglas que
describen cmo mostrar los elementos del documento solicitado, al tiempo que
proporciona mecanismos que independizan esta presentacin del contenido y de la
estructura del mismo. As, en la actualidad, todava usamos sintaxis de la forma:
BODY {font-family: "Arial sin serigraf}
donde su primera parte (BODY) llamada selector, es la porcin de la regla que
selecciona el elemento al cual va a aplicarse (en este caso, "selecciona al elemento
HTML <body>) y la segunda parte {font-family: "Arial, sin-serigraf} llamada
declaracin consistente en un conjunto de propiedades con sus valores asociados
(la propiedad font-family es el tipo de fuente de letra a utilizar y los valores, "Arial
y sin-serigraf son los valores para conocer cmo obtendr la informacin del
usuario).

1#2#,# 4/ML & la de(inicin de tio de documento
Con internet ya en perspectiva, surgi SGML (stndar GML) donde en un documento
ya se diferencia entre su correspondiente estructura fsica y lgica con una
organizacin por un lado, como un conjunto de entidades, y por otro, como una
jerarqua de elementos, de forma que el mercado describe la estructura de la
14
informacin y el texto el contenido. Con SGML existe la posibilidad de definir distinto
tipos de documentos y aunque habra que esperar hasta la aparicin del XML para
tener un lenguaje de marcas definido en trminos de una gramtica formal, en el
desarrollo de SGML aparece el concepto de 787 37ocument 8ype 7efinition6, un
procedimiento para expresar una pseudos gramtica de documentos, basado en una
especificacin de reglas, que permite validarlos automticamente y de esta manera,
hacer que la estructura de cada tipo de documento quede especificada de forma
estricta.
Al ser una DTD "un conjunto de reglas., lo hace distinto a "un conjunto de
declaraciones formales efectivas., que es la forma como la teora de lenguajes
presenta las gramticas; por ello las DTD no llegan a ser una gramtica formal, ya
que su introduccin tuvo un carcter ms pragmtico que terico, y slo ms tarde,
se alineara parcialmente con la teora de lenguajes.
Para ver el papel de las DTD, considrese la elaboracin del catlogo de una
biblioteca, donde cada libro debe tener una ficha con el mismo formato basado en
algn mtodo de catalogacin; en este caso, el uso de DTD permite asegurar que
cada dicha es vlida ya que si hubiera alguna incorreccin no sera validada, lo que
permite su correccin antes de proceder a su procesamiento. Las ventajas de su uso
son:
a) Facilitar cambios en el formato, ya que basta con modificar su DTD
b) Asegurar, incorporando una DTD al editor que se une, que slo se puedan
introducir etiquetas donde est permitido.
c) Sacar partido a los ML. Valga el ejemplo del Chemical Markup Language
(CML), definido sobre SGML que facilita el intercambio de datos en qumica
molecular y con el que los qumicos intercambian datos siempre de la misma
forma, gracias a las DTDs previamente acordadas.
d) Permitir el trabajo conjunto de muchas personas escribiendo un mismo
documento, pues al usar una DTD, se obtiene conciencia e integridad,
condiciones bsicas para trabajar cooperativamente.
e) Poder desarrollar programas "validadotes que comprueben si un documento
est de acuerdo con las con las especificaciones de una determinada
definicin.
Gracias a la identificacin de la estructura de un documento mediante el mercado,
ya en 1974, se demostr que se poda construir un software capaz de, dado un
documento, analizar su estructura y su sintaxis con la capacidad de validarlo sin
15
tenerlo que procesar. Ello abra la puerta a desarrollos que culminaron con la
adopcin del SGML como un estndar internacional.
En el prximo captulo estudiaremos las DTD con ms profundidad, ya que a pesar
de provenir de SGML, forman parte de la recomendacin actual de XML.
1#2#2# "TML. el recio de un comromiso

Aunque sea perfectamente comprensible que en el diseo inicial de la Web se
recurriera a un sistema de representacin tan simple como HTML, hay que aclarar
que a pesar de su extraordinario xito y gran papel en el desarrollo de la Web,
desde el punto de vista de la evolucin de lo ML no supuso un gran avance, y en
consecuencia, hay que considerarlo como una especie de parntesis dentro de esta
seleccin dedicada a los antecedentes del XML.
La quizs excesiva simplificacin del SGML que supuso HTML hizo que
desapareciera la DTD, cosa que dio una gran libertad, aunque a la larga esta
simplificacin acabara evidenciando sus carencias. Cuando la Web se desarrollo
plenamente se evidenci la necesidad de tener que volver al concepto de documento
vlido, en el sentido de estar conforme con determinadas restricciones, que como
vemos se expresan en la llamada declaracin del tipo de documento.
Para valorar la trascendencia de la simplificacin hecha con el HTML, hay que
sealar que incluso DTD presentan limitaciones en la Web actual, y el propio
concepto de validez se ha tenido que extender con el uso de mecanismos que van
ms all de los usados en las DTD. Nos referimos a los Esquemas XML (que se vern
en su movimiento) que definen la estructura y el tipo de datos que puede contener
un documento, especificando elementos, atributos y tipos de datos que se pueden
utilizar junto a la estructura que debe seguirse para que el documento pueda ser
considerado vlido.
A pesar de haber sido diseado expresamente para la Web HTML, gracias a su
facilidad para crear documentos, empez a unirse en otros mbitos, lo que
involuntariamente hizo ms patente sus limitaciones para tareas ms elaboradas
que la simple presentacin del documento.
A mitades de los 90, cuando las pginas Web pasaron de estadsticas a dinmicas,
se pusieron de manifiesto carencias de escalabilidad, servicios comunes, seguridad,
etc., lo que aconsej una nueva visin para obtener un entorno de desarrollo que
permitiera construir y desplegar aplicaciones distribuidas a gran escala.
16

1#2#5# $e "TML a XML. la searacin datos6resentacin
Las pginas dinmicas suponen una nueva interaccin con el usuario y ello hizo
patente la necesidad de cambiar y extender las interfaces, cosa nada fcil pues los
datos del cliente son cadenas que el servidor debe decodificar explcitamente y las
interfaces no eran suficientemente auto-descriptivas. Se impona retomar la senda
marcada por SGML y superar algunas limitaciones propias de HTML (mezclar
marcado estructural y presentacin, dificultad de procesamiento computacional,
inconvenientes en la visualizacin de documentos en determinados idiomas,
interpretacin ambigua, etc.).
La conclusin fue que Web necesitaba un marco amplio para enfrentar los temas
relacionados con la informacin, y por ello, la nueva especificacin ya no versara
tanto sobre un lenguaje especfico, sino sobre una forma de disear nuevos
lenguajes y los correspondientes procedimientos para analizarlos, que fuesen
compatibles con las caractersticas de la Web. Se trataba de modificar las
especificaciones existentes para que datos y presentaciones se independizaran
definitivamente, aunque siempre aprovechando todo lo que se habia construido y se
construa en HTML.
En 1996, en el seno de W3C, se puso en marcha el Grupo de Trabajo de XML
(originalmente conocido como el comit de revisin editorial de SGML) presidido por
John Bosak de SUN. Los requisitos que impusieron para este diseo fueron:
- Utilizable directamente sobre Internet
- Una amplia variedad de aplicaciones
- Compatibilidad con SGML
- Facultad para desarrollar programas que proceden sus documentos
- Reduccin de caractersticas opcionales, idealmente ninguna
- Obtencin de documentos legibles para los humanos
- Diseo de documentos formal y conciso
La primera recomendacin XML del W3C sali en febrero de 1998 y estaba basada
en otros estndares ya existentes tales como: Unicode ISO/IEC 10646 para
caracteres, Internet RFC 1766 para marcas de identificacin, ISO 639 para cdigos
17
de lenguajes natural e ISO 3166 para los cdigos de nombres del pas. En este
estndar se describen tanto los documentos XML como el comportamiento de los
programas que los procesan.
1#5# $ocumentos XML
Si se considera el documento novela se observa que est estructurado en un ttulo y
en diversos captulos, cada uno de los cuales, a su vez, consta de un ti ttulo y de
diversos prrafos, etc.; si se hace lo mismo con el documento art+culo cient+fico, ste
presenta, adems de ttulo, un sumario, distintas secciones (instruccin, material y
mtodos, resultados, bibliografa, etc.) cada una de ellas con su subttulo y
apartados, y en ambos documentos de descomposicin puede continuar hasta llegar
a las frases, palabras y caracteres, siempre siguiendo la pauta de un uso de
elementos, debidamente nombrados, ordenados y animados. Esta aproximacin
pone de manifiesto que cualquier tipo de documento pueda acabar obedeciendo a
una estructura de rbol, un caso particular de grafo etiquetado al que nos referimos
al hablar de dato semiestructurado.
Para avanzar en este sentido sea el siguiente listado:
<!-ejemplo de un documento-> comentario
<universidad>
<departamento> nombre
<nombre>
Departamento de informatica elemento
</nombre>
<direccion>
constitucin 234
</direccion>
</departamento> etiqueta
</universidad>
cuya estructura se plasma de forma que su contenido est marcando de una manera
previamente acordada y autodescriptiva (para los humanos) gracias a las eti-uetas
y que estn descompuestas en elementos, algunos de ellos anidados. Estos
elementos son unidades significativas de informacin dentro de los que existe un
cierto texto y tambien en el ejemplo se nota la posibilidad de incluir comentarios#
Obsrvese que si una persona sabe castellano, al leer el documento XML anterior
tiene una idea acerca de lo all representado, sin embargo para un mdulo de
software (salvo que incorpore algn tipo de inteligencia artificial) ste carece de
cualquier significado semntico. En consecuencia para que la informacin sea
18
accesible para un computador, es obvia la necesidad de disponer a un analizador
que lea cada carcter hasta encontrar un smbolo, <, que le indica el inicio de una
etiqueta y seguir hasta que encuentre, >, y que interprete que lo ledo entre medias
sea considerado como un inicio de elemento. Y as hasta encontrar una etiqueta
</. . . .> que significa el final del elemento, de forma que este proceso se repita con
todo el archivo. Este proceso de anlisis se inicia, por tanto, con la bsqueda de
pares de etiquetas y de sus contenidos respectivos y debe seguir para poder
entender la estructura global del documento.
Como se habr notado, el ejemplo demuestra un grafo para datos
semiestructurados usando la estructura de rbol con raz, donde cada nodo tiene un
contenido, caracterizndose el nodo ra)7 del rbol por la propiedad que su contenido
no puede aparecer en los contenidos de ningn otro nodo (o elemento) y al
contrario, el resto de elementos estn contenidos en l. Siguiendo la nomenclatura
de rboles se habla de nodo adre de nodo hijo; por ejemplo: <raz> Este elemento
raz es el padre del elemento "padre
<padre> Este elemento `padre en un hijo del elemento "raz y
padre del elemento "hijo.
<hijo> Este elemento es un hijo del elemento "padre. </hijo>
</padre>
</raz>
La conclusin de lo dicho es que un documento se acaba reduciendo a una
sucesin de caracteres estructurada en forma de rbol, con una particin po
etiquetas que con una buena sintaxis proporcionan su connotacin. Se trata, por
tanto, por un lado de retener dos principios estructurales: el orden y la jerarqua, y
por otro, con las herramientas correspondientes.
Al contrario que HTML, XML y sus tecnologas asociadas especifican cmo
interaccionar y explotar el contenido de un documento y, en lnea con SGML, separar
datos y presentacin, de forma que XML no incorpora ninguna semntica intrnseca
de presentacin. Tan radical es esta posicin, que si no se contase con tecnologas
adicionales no se sabra cmo representar el contenido de un documento, como no
fuera en forma de una cadena indiferenciada de caracteres, y de hacho XML empez
su camino sin que ningn navegador fuera capaz de mostrar sus documentos como
si fueran en forma de un simple texto, aparentemente un paso hacia atrs respecto
al HTML, que s cuenta con aplicaciones que interpretan el documento de una pgina
Web y lo introducen en texto e imgenes formateadas. Como veremos, XML se ha
dotado de tecnologas adicionales que permiten resolver y superar las posibilidades
de presentacin del HTML.
19
1#8# La (amilia XML en la nueva Web
La Web, tanto cuantitativa como cualitativamente, se ha desarrollado
extraordinariamente siendo el objetivo de este texto ubicar el papel que XML juega y
va a jugar en esta evolucin. La siguiente figura, adaptada de la W3C, muestra
cmo en la base de la componente de la Arquitectura de la Web correspondiente a la
representacin de datos, aparece XML con el objetivo de garantizar la
interoperabilidad, lo que supone contar con gramticas para escribir documentos
que sean estables y transmisibles.
Junto a XML figuran una serie de tecnologas y lenguajes que permitirn cubrir los
objetivos del lenguaje y que en conjunto constituyen la llamada (amilia XML, que
proporciona herramientas, tanto para descubrir de forma estructurada cualquier tipo
de dato, como para manipular documentos.
FIGURA
Sobre la familia XML, la figura muestra una serie de herramientas para crear
lenguajes y vocabularios que describes datos en cualquier campo o rea de actividad
en la que se necesiten (grficos, frmulas matemticas, aplicaciones financieras,
etc.), y as enfrentar las mltiples demandas de la Web que sta evolucionando de
una Web de documentos a ser una Web de datos y servicios.
Los documentos XML por s solos no tienen demasiando valor, slo son archivos de
texto, para que se muestren tiles hay que poder acceder a sus datos, cosa que
hace la familia XML y ya cuando se puede acceder a estos datos se utiliza el
documento para una aplicacin determinada. Clarifiquemos la terminologa al
respecto.
Una alicacin XML es una clase de documento XML definido con una
especificacin o conjunto de reglas adicionales a la propia familia XML. Por tanto hay
que distinguir entre una aplicacin XML y las piezas de software que de algn modo
procesan documentos XML, como el editor XML para Windows, el navegador Web
Mozilla, o un conversor a PDF que son "aplicaciones en el sentido tradicional del
trmino, pero que estrictamente no seran "aplicaciones XML.
Basado en la familia XML existe un gran conjunto de sublenguajes producidos para
una larga serie de aplicaciones XML, entre la que dentro del universo de siglas
existentes, conviene distinguir por un lado los llamados vocabulario ara
alicaciones hori7ontales (situados por encima de la fila de la familia XML en la
figura) que proporcionan mecanismos, basados en la familia XML, para resolver
tareas genricas tales como la interpretacin, la presentacin, la seguridad, etc. Y
20
por otro lado, vocabularios ara alicaciones XML en di(erentes dominios del
conocimiento% llamados tambin aplicaciones de dominio en las que cada sector
de actividad define sus correspondientes vocabularios con los elementos propios de
su estabilidad y campo especfico de aplicaciones. Quizs con una excesiva
simplificacin podemos decir que la W3C, adems de las de la propia familia XML,
tiene a su cargo la elaboracin de las recomendaciones de las tecnologas
horizontales mientras que organizaciones como OASIS (Organization for the
Advancement of Structured Information Standards) y otras, hacen esta funcin con
el segundo grupo de aplicaciones, donde la carga tecnolgica es mucho menor.
En consecuencia, a la hora de abordar el estudio de la tecnologa XML, conviene
distinguir estos tres niveles:
- tecnologas de la familia XML.
- Aplicaciones y vocabularios XML horizontales.
- Aplicaciones XML con vocabularios de dominio.
Aunque en el ltimo captulo intentaremos organizar la frondosa variedad de estos
dos ltimos aspectos, el presente texto se centra en la familia XML, que constituye
el conjunto de recomendaciones que proporcionan la base para soportar el uso de
XML en la arquitectura de la Web, y que son:
- +sacio de nombres. XML proporciona la libertad para que cada una pueda
desarrollar su propio lenguaje de marcas, lo que hace que surja la posibilidad
de que aparezca etiquetas iguales con diferente estructura o significado.
Cuando se trabaja en red estos vocabularios se puedan mezclar, y el riesgo de
confusin es inevitable, razn por la cual se necesita un mecanismo, llamado
+sacio de Nombres (Namespaces) que ayude a resolver estos problemas de
forma que cada etiqueta pueda ser considerada en su contexto adecuado.
- +structura de documentos con +s-uemas XML# Los Esquemas
proporcionan un mecanismo para definir la estructura y semntica del nivel
bsico de los documentos XML. Como se ha dicho, son una alternativa a las
DTDs, y tienen como una de sus caractersticas principales la posibilidad de
definir tipos de datos, as como el uso de la propia sintaxis XML.
- 0ecorre un documento# Xath es un lenguaje que permite especificar la
localizacin de los componentes de u documento XML, basado en el
procesamiento del mismo asocindole una estructura en forma de rbol.
Adelantemos que si se quisiera obtener los elementos de un catlogo con
Xpath, es posible seleccionar cada artculo por su posicin en el documento (el
primero, el vigsimo, el ltimo, etc.), o por alguna de sus propiedades o
atributos. Adicionalmente a las funcionalidades de Xpath, otra tecnologa
21
Xointer permite referirse y localizar fragmentos del documento con ms
granularidad.
- *nclusin & v)nculos entre documentos# Uno de los aspectos ms
poderosos de la Web en su capacidad para enlazar documentos entre s, de
forma que la facilidad que supone hacer un "click sobre un hipervnculo y
acceder al documento deseado no se puede comparar con la de hacer lo
equivalente con documentos impresos, por muy a mano que se tengan. Por
ello los mecanismos de enlace en XML son bsicos; en esta lnea, las
recomendaciones XLin9 & X:ase especifican informacin relacionada con el
enlace entre documentos.
Xlink permite distintos tipos de enlace, desde el monodireccional de un
documento que apunta a mltiples documentos, hasta el bidireccional que
fluye entre dos documentos. Esto hace que XML tenga propiedades de enlace
muy flexibles, superando las propias del HTML.
Existen situaciones en las que el enlace entre documentos no es lo ideal, y
lo que se requiere es construir un gran documento a partir de un conjunto de
ellos ms pequeos. Con este objetivo Xinclude proporciona mecanismos
para incluir varios documentos en la estructura de uno solo.
- Consultas# La experiencia de trabajar con bases de datos pone de manifiesto
que sin un diseo correcto de su estructura (el esquema) los mejores datos
del mundo pueden ser intiles sin un sistema de consulta. Por ello, la W3C ha
creado sistemas de consulta X;uer& con la estructura de documentos XML
como base, para proporcionar mecanismos basados en XPath para localizar
datos en documentos XML.
- Trans(ormaciones# El texto de un documento XML est disponible para
cualquier aplicacin que pueda acceder a sus archivos texto, y hay que poder
procesar automticamente este texto, para cualquier actuacin como por
ejemplo proceder a su presentacin. Sin embargo, los archivos XML no
contienen ni ninguna informacin referida a cmo efectuar este procesado,
por lo que es necesario poder facilitar toda una variedad de transformaciones.
Para que ello sea posible, X4LT (Extended Stylesheet Language
Transformation) proporciona un leguaje XML basado en reglas que
transforman un documento XML en otro, tambin basado en texto, de acuerdo
con las indicaciones que le d una hoja de estilo que vara segn sea el
resultado final que se le persigue. Tras este proceso de transformacin, el
documento resultante puede ser muy distinto de la fuente.
Una de las funcionalidades ms importantes de XSLT reside en la
posibilidad que proporciona que un mismo documento fuente pueda
publicarse con toda libertad, sobre no importa qu tipo de perifrico, usando
la hoja de estilo adecuada a cada caso. XSLT al procesarse transforma un
22
documento, y estas transformaciones no se restringen a las presentaciones,
ya que tiene otras utilidades referidas a preparar el documento para otras
aplicaciones.
- 1ave'acin interna or el documento# Uno de los mecanismos que
permiten la interaccin de documentos XML con entidades externas se basa en
el acceso a travs de un modelo de navegacin, bien para que desde el lado
del cliente se interacte con una parte del documento XML, bien para que del
lado del servidor se interacte con el documento para generar un contenido
adaptado.
$OM (Document Object Model) es un conjunto de especificaciones de la W3C
para desarrollar estndares que permitan a los distintos lenguajes de
programacin interactuar con documentos XML. Su objetivo es proporcionar
una interfaz que sea independiente tanto de la plataforma computacional,
como del lenguaje de programacin, de forma que DOM proporciona un
conjunto, un modelo, y una interfaz estndar para representar, acceder,
combinar y manipular documentos.
DOM es un API (Application Programming Interface) que manipula todo el
documento en forma de rbol, lo que supone utilizar una gran potencia de
clculo ya que trabaja con la totalidad del documento. Una alternativa al
consumo de memoria asociado al procesamiento basado en DOM se basa en el
uso de un API que no lea el documento completo, sino que acte en funcin de
los acontecimientos que se registran en la lectura del mismo, este es el caso
de SAX (Simple API for XML) que permite trabajar slo con partes de
documento y por lo tanto aligerar la interaccin con el mismo.
23
, Ca)tulo
Tecnolo')as & concetos revios al XML

XML, nacido a partir de SGML, incorpora tecnologas ya existentes en el momento de
su especificacin, lo que supone introducir ciertas particularidades en el seno de la
recomendacin XML que a veces llaman la atencin. Por ello es oportuno presentar
estos conceptos previos a la propia aparicin de XML, y que directa o indirectamente
estn incorporadas en la familia XML.
,#1# Unicode. el al(abeto de los documentos XML
El uso de Unicode es un requisito impuesto a XML para la codificacin de los
caracteres de sus textos. Como es sabido, este sistema de codificacin naci con el
objetivo, perfectamente alcanzado, de poder procesar la totalidad de los caracteres
de los lenguajes actualmente existentes en el mundo.
Unicode define la codificacin de ms de 90.000 caracteres individuales, asignando
a cada uno un nmero (por ejemplo: 64.812) de forma que todo dato, representado
por lo miembros de un determinado conjunto de caracteres, tiene su particular
soporte en bytes. Para manejar eficientemente toda esta cantidad de caracteres,
Unicode combina diferentes codificaciones, de forma que un mnimo carcter puede
usarse con diferentes secuencias y/o nmero de bytes, y as mismo usar diferente
nmero de bytes para caracteres distintos.
Unicode supera situaciones propias de determinados sistemas de codificacin,
como por ejemplo que el conjunto ISO-8859-7 incluya letras griegas, mientras que
2.1. Unicode: el alfabeto de los
documentos XML
2.2. DTD
2.3. Las gramticas formales
2.4. CSS
24
el conjunto ISO-8859-1 no lo hace. La forma de enfrentarse a ello, por parte de
Unicode, reside en la idea de que el hecho de cambiar el conjunto de caracteres
representables puede suponer cambiar la codificacin interna de estos caracteres,
pero ello no tiene porqu influir en los caracteres que pueden usarse y en
consecuencia, trabaja simplemente cambiado, segn la necesidad, la forma como
cada carcter se codifica en bytes.
En conexin con lo anterior, los analizadores XML incorporan la doble capacidad
de, por un lado, convenir unos caracteres en otro antes de presentarlos a la
aplicacin, y por otro, saber cmo tratar otros conjuntos de caracteres con
codificaciones basadas en los diferentes subconjuntos de Unicode. De esa manera,
XML realmente no deja nunca cambiar el conjunto de caracteres, ya que siempre es
Unicode, y slo lo ajusta a cada uno concreto. El que la universidad no se consiga,
en la medida que sera deseable no es achacable a XML sino a la forma de trabajar
de muchos autores de documentos, que se ha acostumbrado, por comodidad, a
trabajar con determinados subconjuntos de cdigos.
TABLA 2.1.
La frase: "Bienvenida al mundo de Unicode puede escribirse:

&#1571;&#1607;&#1604;&#1575;&#1611;&#1576;&#1603;&#1605;&#1601;.
Sealemos que en XML puede usarse cualquier carcter de Unicode, a excepcin
de los que tienen algn significado especial para el lenguaje y que son
concretamente: & (utilizado para dar un texto que remplaza a una entidad), <, >,
(usadas para las etiquetas) , "(reservados para delimitar valores de atributos) para
cuyo uso, como veremos, XML usa un mecanismo basado en la referencia de
entidades.
,#,# $T$
Aunque las DTDs forman parte de la recomendacin XML, hay que recalcar que nos
encontramos con una aportacin procedente de SGML incorporada XML. Por esta
razn situamos su presentacin antes de estudio sistemtico del XML, ya que es una
tecnologa previa al XML que era usada como mecanismo, para determinar la validez
de un documento (como tendremos ocasin de ver, ya dentro del marco estricto de
XML; tambin se encargan de ello los Esquemas XML).
25
Una DTD es una coleccin de declaraciones de elementos (ELEMENT), atributos
(ATTLIST), entidades (ENTITY) y notaciones (NOTATION a partir de las cuales se
describe la "validez de un documento. Se define siguiendo la sintaxis:
<! DOCTYPE nombre [
.........
]>
de forma que este nombre se referenciar en el documento XML junto con la URI
donde localizarlo, en la seccin dedicada a declarar el tipo de documento XML a
validar.
La forma como se puede organizar un documento que describa una DTD es
bastante libre, aunque sea conveniente seguir el mismo orden con el que se van a
presentar los objetivos en el documento XML, definido por tanto en primer lugar los
objetos que aparecen primero y/o que pueden ser incluidos en otros elementos, para
luego definir el resto de elementos.
,#,#1# $eclaracin de +lemento#
Los elementos de una DTD son los bloques primarios de todo documento y se
declaran de la forma:
<! ELEMENT nombre (modelo de contenido)>
esto es, se empieza con "<!ELEMENT, seguido de un nombre llamado identificador,
y los parntesis que siguen especifican el contenido que sta permitido, por lo que
se conoce como especiali4acin o modelo de contenido, que a su vez puede contener
ms elementos, crendose as una posible cadena de subelementos anidados entre
s.
La virtualidad de esta declaracin reside en la idea de definir las relaciones
existentes entre los distintos elementos de un documento. Dado:
<! DOCTYPE etiqueta [
<! ELEMENT receta (plato, ingredientes, preparacin)>
<! ELEMENT plato (#PCDATA)>
<! ELEMENT ingredientes (#PCDATA)>
<! ELEMENT preparacin (#PCDATA)>
]>
26
el elemento receta contiene a su vez los elementos plato, inredientes y
preparacin, que a su vez, estn definidos tambin en la DTD.
Los modelos de contenido que puede tener un elemento son:
- #PCDATA: conocido como "Parser Character Data, esto es, un dato que debe
ser objeto de anlisis. El carcter # significa algo parecido a "tipo, as al
escribir:
<! ELEMENT miElemento (#PCDATA)>

se indica que mi)lemento debe contener un tipo de dato analizable.
- Otro elemento (o elementos): como se ha dicho, el contenido de un elemento
puede ser otro(s) elemento(s), como es el caso de:
<! ELEMENT clase (profesor)>
que indica que la clase slo puede contener un solo elemento profesor.
En el caso que tenga varios subelementos como contenido, se habla de
secuencia, que adems determina el orden en que aparecen stos, presentndolo
siempre separados por comas; por ejemplo:
<! ELEMENT clase (profesor, aula)
especifica que el elemento clase, debe contener un elemento profesor seguido de un
elemento aula.
- EMPTY: el elemento no tiene contenido y se llama elemento vaco
escribindose de la forma:
<! ELEMENT salto-de-pagina EMPTY>
- ANY: indica que el elemento puede tener cualquier contenido (aunque es muy
conveniente que lo elementos estn adecuadamente estructurados). Este valor
admite la posibilidad de que el elemento pueda tomar valores tan distintos
como PCDATA, elementos o una combinacin de PCDATA y elementos (incluso
elementos vacos): por ejemplo:
<! ELEMENT batiburrillo ANY>
27
- MIXED: indica que el elemento puede tener caracteres de tipo dato o una
mezcla de caracteres y subelementos, pero al contrario que ANY sus
contenidos deben estar debidamente especificados: por ejemplo:
<! ELEMENT nfasis (#PCDATA)>
<! ELEMENT prrafo (#PCDATA | nfasis)>
el primer elemento <n(asis puede contener datos de carcter (#PCDATA), y el
segundo =rra(o puede contener tanto datos de carcter como subelementos
de tipo <n(asis.
Se usa el carcter barra (|) para separar las distintas opciones, con el
significado de "o exclusivo; por ejemplo:
<ELEMENT postre (helado | pastel)>
indica que el ostre puede contener bien un elemento helado bien un
elemento pastel. El nmero de opciones no sta limitado a dos, y se pueden
agrupar usando parntesis, de la forma:
<! ELEMENT postre (sorbete, (helado | pastel))>
En la especificacin de contenido se puede incorporar al identificador (tambin
a una secuencia de ellos o a una opcin) un smbolo de frecuencia, de acuerdo
con la siguiente Tabla de significados:
TABLA 2.2.
A escribir <! ELEMENT aviso (titulo?, (prrafo+, grafico)*)>
Se especifica que aviso puede tener titulo o no (pero slo uno), y tener cero
o ms conjuntos de la forma: (prrafo, grafico), (prrafo, prrafo, grafico),
etc. En el ejemplo:
<DOCTYPE formato [
<! ELEMENT formato ( #PCDATA| bold | italic)*>
<! ELEMENT negrita (#PCDATA)>
<! ELEMENT italica (#PCDATA)>

]>

la lnea <! ELEMENT formato ( #PCDATA| bold | italic)*> declara el
elemento (ormato de contenido mixto que puede contener bien caracteres de
datos (PCDATA), o el elemento negrilla, o el elemento itlica y el contenido
28
puede darse ninguna o varias veces; mientras las dos lneas que siguen
especifican que ne'rita e italica solamente tienen PCDATA como modelo de
contenido.
,#,#,# $eclaracin de atributo
Una declaracin de atri*uto permite aadir informacin sencilla y desestructurada de
los elementos de un documento; puesto que puede existir ms de un atributo por
elemento, se utiliza una lista para ello en la llamada declaracin de lista de atri*utos
(ATTLIST) cuya forma es:
<! ATTLIST elemento nom*re del atri*uto TYPE Palabra clave>
En esta sintaxis, tras <! ATTLIST aparece sucesivamente: un espacio en blanco, el
identificador del elemento al que se aplican el atributo, el nombre del atributo, su
tipo, finalizando con una palabra clave. Ejemplos son:
<! ELEMENT texto (#PCDATA)>
<! ATTLIST texto idioma CDATA #REQUIRED>
<! ELEMENT mensaje (de, a, texto)>
<! ATTLIST mensaje prioridad (normal | urgente) normal>
donde se inicia que el atributo idioma pertenece al elemento te!to pudiendo
contener casi cualquier carcter, mientras que el atributo rioridad pertenece al
elemento mensa3e y puede tener el valor "normal o "urgente, siendo "normal el
valor por defecto si no se especificara este atributo en el documento.
Respecto a la palabra clave >REQUIRED significa que no tiene valor por defecto,
por lo que es obligatorio especificar este atributo. Si el atributo es opcional, se usa la
clave >IMPLIED ya que a veces interesa que se pueda omitir un atributo, sin que se
adopte automticamente un valor por defecto; por ejemplo:
<! ATTLIST IMG URL CDATA #REQUIRED>
<! ALT CDATA #IMPLIED>
expresa que el atributo "URL es obligatorio, mientras que el atributo "ALT es
opcional y si se omite, no se toma ningn valor de defecto.
La tercera palabra clave >FIXED especifica que el valor del atributo es constante,
y no puede cambiar a lo largo del documento. Al escribir:

29
<! ATTLIST cdigo postal #FIED "46110 >
se indica que 46110 es el nico cdigo postal que se va a utilizar:
Los posibles tios de atributo que existen son:
- Cadenas CDATA (datos de caracteres) que pueden tomar como valor cualquier
secuencia o cadena de caracteres a excepcin de los smbolos con significado
especial: <, >, &, , ".
- *$ indica que el atributo tiene un nombre definido, y con su uso se determina
el valor aceptable para cada instancia del elemento el que se aplica.
Supngase que al relacionar la plantilla de una empresa a cada empleado se le
asigna su nmero de seguridad social (nss), para ello si se declara en la DTD:
<! ELEMENT empleado (#PCDATA)>
<! ATTLIST empleado nss ID #required>

se trata de iniciar que cada empleado tenga su nss y que dos empleados no pueden
tener el mismo.
- IDREF. Mientras ID identifica a un elemento, IDREF apunta a un elemento con
un atributo ID. Por ejemplo, para implementar un sistema de hipervnculo en
un documento podemos utilizar:
<! ELEMENT enlace EMPTY>
<! ATTLIST enlace destino DIREFUL #REQUIRED
El tipo de ID y el mecanismo de referencia es muy parecido al utilizado en los
sistemas de gestin de base de datos y hechos, las estructuras en las DTDs
pueden llegar a ser casi tan complicadas como las claves lo son en aquellos
sistemas.
- )numeraciones# Corresponde a atributos que slo pueden contener un valor de
entre un nmero reducido de opciones, que aparecen en una lista
proporcionada en la propia declaracin (de aqu que se hable de enumeracin)
donde, adems uno de estos valores se indica como valor por defecto. Por
tanto, la eleccin del valor del atributo se limita a los valores que aparecen
entre parntesis y separados por el smbolo "|; As la expresin:
9! ATTLIST telfono lugar (oficina | mvil | particular) "oficina>
proporciona la localizacin de un nmero de telfono y si ste dato no sta
presente, la localizacin del nmero de telfono se asume que por defecto que
es el de la "oficina.
30
- NMTOKEN (Autenticaciones6 son parecidos a las cadenas CDATA, aunque
importen restricciones sobre los valores de los atributos, de forma que slo
aceptan caracteres vlidos para nombrar cosas (letras, nmeros, puntos,
subrayados y los dos puntos). En el ejemplo:
<! ATTLIST pas poblacin NMTO!EN #REQUIRED
ais poblacin = "5000000 sera aceptado, pero no lo sera si el valor fuera
escrito de la forma "5 000 000 debido a la presencia de espacios en blanco.
- ENTITY permite especificar un atributo cuyo valor sea una entidad, a la que
nos vamos a referir a continuacin.
,#,#2# $eclaracin de entidades
Este tipo de objeto ya apareci en el Captulo 1 cuando se introdujo el concepto de
documento; en general entidad se refiere a un objeto usado para guardar
informacin y por ello necesariamente cada documento tiene al menos la entidad del
propio documento. Su razn de ser es doble, permitir guardar un contenido que
puede usarse muchas veces y poder descomponer un documento grande en
subconjuntos ms manejables. De la misma forma que los elementos describen la
estructura lgica de un documento, las entidades mantienen la coherencia de la
localizacin de los paquetes de bytes que constituyen la correspondiente estructura
f+sica, de forma que el concepto de entidad permite descomponer un documento en
distintas unidades fsicas contenidas en una o ms unidades de almacenamiento.
Una entidad como coleccin de datos definidos y almacenados separadamente,
tiene un nom*re que sirve como referencia que "apunta a la entidad. Las entidades
se declaran mediante el uso de: <! ENTITY...existen tres tipos de ellas:
- +ntidad interna. la ms sencilla consiste en abreviaturas definidas dentro de
la DTD, de forma que no se maneja ningn objeto de almacenamiento fsico
diferente al del propio documento, y su contenido coincide con el que se da en
su declaracin. Su sintaxis es:
<! ENTITY nom*re valor$:
donde nom*re es el nombre de la entidad y valores la cadena de sustitucin
correspondiente. Por ejemplo, si se define una entidad una cantidad llamada
derechos para una publicacin de un libro, se utilizara:
31
<! ENTITY derechos "Copyright 2002
En una entidad interna se llama te!to de reemla7amiento al contenido de
una entidad despus de haber reemplazado los textos de caracteres de forma
que, una vez reemplazada, pasa a ser una parte del documento y como tal es
analizada.
- +ntidad e!terna. difiere de la anterior en que su contenido no sta dentro de
la propia DTD, sino en cualquier otro sitio del sistema (otro archivo, un objeto
de una base de datos, etc.). Se hace referencia a su contenido mediante una
URI precedida de la palabra PU"LIC O SYSTEM (segn pueda o no accederse a
l sin ms); su sintaxis es:
<! ENTITY nom*re SYSTEM "URI>
con ello, el texto de reemplazamiento correspondiente a nom*re se lo indica al
analizador la palabra clave SYSTEM o PU"LIC, para dirigir al recurso externo
nombrado por el URI que proporciona el valor de la entidad; por ejemplo:
<! ENTITY intro SYSTEM http://www.miservidor.com/intro.xml>
El papel que juegan las entidades externas es importante, pues permiten
descomponer grandes archivos en unidades ms pequeas, con lo que facilitan
su procesamiento incluso por sistemas con capacidades de clculo modestas.
- +ntidad aram<trica. permiten agrupar datos dentro de la DTD para
poderlos escribir de forma abreviada; se distinguen por el uso de un nombre
encabezado por (%). Su sintaxis es: <! ENTITY % nom*re valor$:#
Cuando se referencia una entidad paramtrica, el procesador la reemplaza de
forma literal por el contenido asignado como valor, el cual puede incluir
marcado sin ninguna dificultad, lo que supone una capacidad de abreviacin.
Por ejemplo en un catlogo de prendas de vestir, algunos elementos
(calcetines, medias, parts, etc.)pueden tener atributos comunes, y si
utilizamos las declaraciones:
<! ENTITY %comu "talla (pequea | mediana | grande) `media
color "(rojo | azul | verde | negro | blanco) `blanco
precio CDATA #REQUIRED
<! ELEMENT calcetn (#PCDATA)>
<! ELEMENT panti (#PCDATA)>
<! ELEMENT medias (#PCDATA)>
32
Al escribir <! ATTLIST calcetn %comun> el analizador interpreta:
<! ATTLIST calcetn
talla (pequea | media | grande) `media
color (rojo | azul | verde | negro | blanco) "`blanco
precio CDATA #REQUIRED
con lo que al hacerlo para cada prenda, se evita escribir informacin
redundante.
,#,#5# $eclaracin de Anotacin
La palabra inglesa notacin tiene sus significados el de "nota o "anotacin, dando
la idea de proporcionar informacin adicional, cosa necesaria en una DTD para
detallar el significado de los datos en un atributo o en una entidad. Por ejemplo, si
se quiere incluir un archivo GIF en un documento, no basta con pegarlo
simplemente, sino que hay que incluir una referencia a un grfico externo, bien
como una entidad.
Para poder utilizar esta informacin, ante hay que proceder a su declaracin, cuya
sintaxis general es de la forma:
<! NOTATION nombre SYSTEM "informacin de notacin>
El nom*re asociado a NOTATION correspondiente a la declaracin de entidad o de
atributo al que se refiere y el parmetro "informacin de notacin se pasa a la
aplicacin correspondiente. Esta informacin puede ser una simple palabra clave
(como "gif), un URL, o cualquier otro tipo de descripcin. Cuando se define una
informacin adicional, esta anotacin puede ser de distintas clases: pblica, un
identificador del sistema que especifica documentacin de la propia anotacin, una
especificacin formal, o un asistente de la aplicacin que contenga objetos
representados en la anotacin. Son ejemplos de ello:
<! NOTATION HTML SYSTEM http://www.w3.org/Markup>
<! NOTATION HTML PU"LIC <-/#$3D##DTD %TML 4&0 TRANSITIONAL##EN>
<! NOTATION gif SYSTEM "gif>
Distingamos su uso en atributos y entidades. Para el caso de hacerlo dentro de
atributos, las anotaciones se declaran aadiendo NOTATION a ATTLIST' lo que
permite al autor del documento especificar en el momento de declarar el atributo
que su valor se ajusta a una anotacin dada. Son ejemplos:
33
<! ATTLIST fecha NOTATION (ISO)DATE * EUROPEAN)DATE+ #REQUIRED>
<| ATTLIST imagen fuente CDATA #REQUIRED TIPO NOTATION (,-.+ #REQUIRED
donde en el Segundo ejemplo se observa que se est en condiciones de usar "gif
como un atributo.
Para su uso dentro de una entidad, el esquema que se sigue es anlogo al interior
y se lleva a cabo incorporando en la entidad externa la palabra clave NDATA.
Veamos el uso de ello en el siguiente ejemplo: supngase que se quiere incluir en la
DTD en el logo de una compaa del que se tienen dos versiones, una GIF y la otra
en JPEG. Se empieza por las correspondientes declaraciones de la anotacin:
<! NOTATION gif SYSTEM "gif>
<! NOTATION "jpeg SYSTEM "jpeg>
Y a continuacin, sta se incjuye en las entidades correspondientes, con las
notaciones de "GIF o "jpeg de la forma:
<! ENTITY logo - gif SYSTEM "imgenes/compaa - logo.gif NDATA gif
,#,#8# 4ecciones Condicionales
Las DTDs tiene la posibiliadad de incluir o ignorar declaraciones, as la palara clave
INCLUDE sirve para especificar las declaraciones que se incluyen e IGNORE las que
son excluidas. El analizador incluye la decalracin de un elemento nombre mediante
la sintaxis:
<![ INCLUDE[
<! ELEMENT nombre (#PCDATA)
]] >
y excluye la declaracin de un elemento mensa3e mediante:
<[ IGNORE[
<! ELEMENT mensaje (#PCDATA)>
]]>
Un ejemplo del uso de estas secciones condicionales se presenta cuando un
documento tiene que ser aprobado o rechazado por un determinado responsable, de
forma que en este ltimo caso hay que especificar una razn para ello, en ambas
situaciones debe aparecer la firma correspondiente. Para ello podemos escribir el
fragmento:
34
<! ENTITY %rechazar "IGNORE>
<! ENTITY %aceptar "INCLUDE>
<![ %aceptar; [
<!ELEMENT mensaje (apropiado, firma)>
]]>
<![ %rechazar; [
<! ELEMENT mensaje (aprovado, razon, firma)>
]]>
<![ %rechazar; [
<! ELEMENT mensaje (aprobado, razon, firma)>
]]>
<! ELEMENT aprobado EMPTY>
<! ATTLIST aprobado estado (verdadero | falso) "falso>
<! ELEMENT razon ( #PCDATA)>
<! ELEMENT firma ( #PCDATA)>
donde:
<! ENTITY %rechazar "IGNORE>
<! ENTITY %aceptar "INCLUDE>
declaran las entidades rechazar y aceptar (con los valores IGNORE e INCLUDE
respectivamente) que al estar precedidas por el carcter %, son entidades
paramtricas y por tanto, slo pueden usarse dentro de la DTD en el que se han
declarado, de forma que ?acetar y ?recha7ar representan INCLUDE e IGNORE
respectivamente.
En la lnea <![ %aceptar; [se representa el inicio de una seccin IGNORE, y en la
lnea <![ %rechazar: [ el inicio de una seccin INCLUDE, pudiendo elegir
fcilmentela declaracin del elemento mensa3e que va a considerarse en cada caso.
,#2# Las 'ram=ticas (ormales
Para poder intercambiar documentos resulta evidente la necesidad de definir la
estructura de los textos correspondientes, y para ello hay que desarrollar
previamente reglas, llamadas gramticas que los definan, a partir de elllas, obtener
los lenguajes adecuados. Inicialmente en GML se desarrollaron las llamadas pseudo-
gramticas, parecidas a las utilizadas en el procesador de texto LATEX, utilizado
comnmente en publicacin cientfica, sin llegar a definir una gramticas formales
como acabara hacindose ms tarde con XML.
35
Como es sabido, las gramticas se pueden definir bien informalmente, esto es con
reglas que gobiernan el funcionamieno de las cosas (que es la aproximacin de las
DTD) o bien formalmente, en el que una gramtica es un ente formal que se usa
para especificar el conjunto de cadenas de smbolos que constituyen un lenguaje y
que se define como una cudrupla G=(ST, SN, S, P), donde:
ST: un alfabeto de smbolos terminales.

SN: un conjunto de smbolos auxiliares introducidos como elementos auxiliares
que no figuran en los terminales
S: un conjunto de axiomas.
P: un conjunto de reglas de produccin, entendiendo como tal la opcin u
Opciones mediante el cual un smbolo no terminal se puede transformar en
Smbolos terminales y/o no terminales.
As, la gramtica del castellano (utilizando la llamada notacin de Backus-Naur
(BCN) cuyo desarrollo se puede encontrar en textos dedicados a la llamada "teora
de autmatas, gramticas y lenguajes formales) puede escribirse:
<Oracin>::= <Fnominal> <Fverbal> | <Fnominal> <Fverbal> <Complemento>
<Fnominal>::=<Sustantivo> | <NomPr> | <Articulo> <Sustantivo>
| <Artculo> <Sustantivo> <Adjetivo>
| <Artculo> <Sustantivo> <Adjetivo>
| < Fnominal >de < Fnominal >
<Fverbal>::= <Verbo> | <Verbo> <Adverbio>
<Complemento>::=<ComDir> |<ComIn> |<ComCir> |<ComDir> <ComIn>
<ComCir
<ComDir>::= <Fnominal>
<ComIn>::= a <Fnominal> | para <Fnominal> | ..
<ComCir> ::= en <Fnominal> | desde <Fnominal | cuando <Fnominal> | ..
Desde, <Sustantivo>, <Adjetivo>, <Adverbio>, <Articulo>, <NomPropio> y
<verbo> seran smbolos terminales.

Al igual que las partculas "a, "de, "en, etc., <Fnominal> no es un smbolo
terminal, aunque mediante las reglas de produccin:
<Fnominal>::= <Sustantivo> | <NomPr> | <Articulo> < Sustantivo>
Llegar a convertirse en un smbolo terminales.
36
El primer axioma o momento donde empezar a desarrollar la gramtica sera en
<Oracin>. Y as, dada la oracin "El agua corre en la calle, se puede descomponer
en sujeto, ("El agua), que a su vez se descompone en artculo y sustantivo, un
verbo ("corre) y un complemento circunstancial ("en la calle) con una forma
nominal de nuevo formada por artculo y sustantivo.
Aunque la gramtica formal para los documentos XML supera el alcance para este
texto hay que saber que sta est plenamente desarrollada y puede encontrarse en:
http://www.w3.org/TR/2004/REC-xml11-20040204/
La posibilidad de contar con una gramtica formal para el lenguaje es una de las
caractersticas ms significativas del desarrollo de la familia XML.
,#5# C44
Al llevar XML al lmite externo, el principio consistente en independizar datos y
presentacin, para que pueda utilizarse resulta imprescindible disponer de
herramientas adicionales que ejerzan un control detallado de la salida del
documento. Una opcin para ello fue recurrir a una tecnologa ya existente CSS
(Cascading Style Sheet), que se aplica con xito a los documentos HTML y que se
us, desde el primer momento, para poder presentar documentos XML.
,#5#1# +l estilo en "TML

En el entorno cientfico, cuna de la Web, era ms importante el contenido del
documento que una presentacin con "estilo, y en consecuencia HTML en sus
primeras versiones no consideraba este concepto de estilo, limitndose a dar
herramientas bsicas para la presentacin. Sin embargo, con la aparicin del primer
navegador grfico, la comunidad de los diseadores grficos plante la carencia de
mecanismos flexibles que permitieran mostrar, con toda la riqueza posible, la
informacin guardada en los archivos. La carencia de un control de estilo en HTML,
desde la perspectiva de estos profesionales, constitua un defecto fundamental, ya
que sin poder controlar con precisin cosas como el color, la posicin precisa de los
pxeles, etc., sus creaciones se convertan en travestis feos en el computador del
usuario.
W3C intuy que haba que proporcionar tecnologas para que los expertos en
presentacin de contenidos pudieran trabajar con la mayor libertad posible al objeto
de que el usuario pudiera entender la informacin con la mayor facilidad posible. La
37
decisin de incorporar al HTML la tecnologa de las hojas de estilo planteadas ya
para GML supuso un cambio cualitativo para mejorar el aspecto de las pginas,
puesto que al aadirlas a los documentos, tanto autores como lectores podan
controlar al detalle las presentaciones. Trabajando con HTML y aadiendo nuevas
etiquetas para hojas de estilo (que adems eran reutilizables) los artistas,
diseadores y tipgrafos pudieron trabajar con bastante independencia del
contenido, lo que result clave para el propio xito de la Web.
Por tanto, en HTML se entiende como hoja de estilo a un documento declarativo,
por ello constituido por una serie de reglas, que describen cmo mostrar los
elementos correspondientes al documento solicitado, al tiempo que proporcionan
mecanismos que independizan la presentacin del contenido de la estructura del
correspondiente documento. Los lenguajes de hojas de estilo se introdujeron no slo
para el problema estricto de una presentacin ms o menos brillante, sino tambin
para incluir caractersticas bsicas a la hora de describir las dependencias y
restricciones que inevitablemente presenta el medio o perifrico en el que se va
presentar la informacin en cada caso. La aparicin de las hojas de estilo supuso un
cambio cualitativo para los diseadores de pginas Web a la hora de mejorar el
aspecto de stas, ya que al incorporarlas, tanto autores como usuarios pudieron
controlar el detalle de las presentaciones, sin sacrificar ni la independencia de los
dispositivos no la posible adicin de nuevas etiquetas.
Existen tres formas bsicas de declarar estilos: como un atributo, como un
elemento o con una referencia a una hoja estilo externa.La primera posibilidad es el
llamado estilo "in line, donde el elemento se declara con el atributo st&le. La
segunda forma consiste en dar estilo a todo un documento y no slo a elementos
como los estilos "in line, para ello se recurre a un elemento st&le que se incluye en
la especificacon que definen las reglas de cabecera (head@ del documento.
Finalmente, la tercera forma de conseguir un estilo es enlace extreno. Esta
aproximancin es la ms interesante con la Web como perpectiva, pues estas hojas
de estilo,adem de ser accesibles desde no importa dnde,al ser reutilizados
reducen el esfuerzo de programacin. Este proceso de ahorro de esfuerzo culminara
con con el concepto de cascada, esto es, la capacidad proporciodas por los
lenguajes de hojas de estilo, llamados CSA (Cascading Style Sheet) que permiten
combinar las informaciones referidas a los estilos procedentes de diferentes fuentes.
En el esfuerzo de conseguir una cierta separacin de contenido y presentacin de
documentos HTML, CSS hizo posible definir en un archivo independiente el formato
de aplicar a los datos, y como adems CSS tiene la prioridad de herencia (todos los
elementos hijo del elemento heredan las propiedades de ste) estos lenguajes
emergieron como una estndar para el diseo de pginas Web. Como veremos en su
momento, el mismo uso de ellas se hace desde un documento HTML, es posible
reproducirlo para un documento XML, por lo que entra en el captulo de tecnologas
38
ya existentes que XML incorpora, aunque en este caso de forma indirecta ya que no
forman parte de la familia XML.
,#5#,# Proiedades C44
Se entienden como propiedades CSS las propiedades fsicas de la representacin
visual de un elemento que son susceptibles de utilizacin a la hora de controlar la
apariencia que va a presentar ste al ser mandado por el servidor al cliente, en
respuesta a una peticin.
En una hoja de estilo las reglas CSS usan como sintaxis el nombre de la
propieded, seguida por dos puntos (:) y de su valor; en el caso de haber ms de una
propiedad, stas se separan con punto y coma (;) de la forma:
SELECTOR {propiedad: nombre; propiedad: valor}
La lista de estas propiedades es muy amplia por lo que se agrupan en cateor+as
en funcin del tipo de representacin visual que alteran. Las categorias bsicas ms
comunes son:
Colores & Aondos# Propiedades relacionadas con el cambio de color del fondo de
los elementos.
Auentes# Propiedades con capacidad de manipular las fuentes del texto que se va
a mostrar, que como se sabe es una cuestin crtica para cualquier lenguaje de
hojas de estilo.
Te!to# Propiedades relacionadas con temas tales como: alineacin, subrayado,
espacio entre letras y palabras, aspecto de los espacios en blanco, etc.
Lista# Esta estructura constituye una forma muy usada de organizar los datos, y
sus propiedades permiten especificar la forma de mostrar contenidos.
Tablas# Esta estructura es otra buena manera de organizar los datos, con un
formato fcil de leer, por lo que CSS proporciona un buen soporte para poder
construirlas.
:ordes# Esta categora de propiedades especifican la forma de dibujar los bordes
alrededor de los elementos que lo incorporen.
+!hibicin# Se entiende como una propiedad de exhibicin o disla& a las
propiedades que determinan la forma como se presenta un elemento en un
39
determinado bloque. Esta categora permite controlar cosas tales como la posicin y
relacin mutua de los elementos en una pgina determinada, tratndola como un
conjunto de zonas rectangulares, que incorporan propiedades de borde, marginado y
relleno.
Adelantemos que este apartado acaba siendo particularmente til cuando se trabaja
con XML, porque en su conjunto, se proporciona un mecanismo para agrupar
"bloquesde cosas, que pueden formatearse como un nico objeto.
M=r'enes# Se entiende como una propiedad mar'en a la que permite determinar
las zonas de la pgina donde no se puede poner texto (mrgenes de pginas,
bloques de visualizacin, etc.).
0ellenos# Propiedades que especifican rea con propiedades determinadas.
A medida que internet y los perifricos para acceder a la web han evolucionado,
W3C ha sido elaborando diferentes versiones de las especificaciones para CSS, que
explotan las posibilidades tecnolgicas disponibles, intentando siempre incluir las
versiones ms antiguas en las nuevas por razones de compatibilidad. Para cualquier
dispositivo utilizado para acceder a internet, que no sea un computador de propsito
general, es fundamental que pueda soportar CSS al objeto de asegurar su capacidad
para representar la informacin que pueda recibir.
XML, al no incorporar ninguna semntica intrnseca cuando empez su camino,
provoc que no existiera ningn navegador capaz de mostrar sus documentos como
no fuera en forma de un simple texto, lo que supona un paso hacia atrs respecto al
HTML, que s cuenta con aplicaciones que interpretan el documento de una pgina
Web y lo traducen en texto e imgenes formateadas. Para XML era imprescindible
disponer de herramientas que ejercieran un controldetallado de esta salida y por ello
se recurri a los CSS, que se adapt al XML sin grandes dificultades.
Como veremos con ms detalles en el Capitulo 8, los ambiciosos objetivos de XML
motivaron que la W3C empezara a tratar de superar las posibilidades de CSS,
impulsando el llamado XSL (Extensible Stylesheet Language), un metalenguaje para
expresar hojas de estilo, de tal forma que dada una clase de documentos arbitraria,
se pudiera definir una hoja de estilo que exprese la forma como un contenido
estructurado en un documento XML pueda presentarse en distintos entornos. En
otras palabras, una forma de hacer que el contenido XML pueda asociarse tanto a un
estilo como a un diseo y a una paginacin de forma que generalice lo que CSS
consigue en la ventana de un navegador.
A pesar del desarrollo de XML, se sigui explotando la idea de emular en XML lo
que CSS hacs en HTML. Actualmente las hojas de estilo se han ido detallando de
forma muy amplia; existen en este momento tres recomendaciones en este sentido:
40
CSS1, CSS2 y CSS3 (Cristalizadoescribiendo el presente texto), siempre tratando de
conseguir el objetivo de separar contenidos y presentaciones respectivas.
El papel del CSS en XML es tan importante que la propia recomendacin W3C, CSS
Nivel 2, incluye un "tutorial para usar XML y CSS y de hecho esta aproximacin
iniciada en 1998 sigue siendo el mtodo ms familiar para presentar documentos
XML en navegadores Web. Tendremos ocasin de volver sobre esta cuestin al inicio
del Capitulo 8.

41
2 Ca)tulo
+scribir $ocumentos XML
3.1. Datos + marcado
3.2. Prlogo de un Documento XML
3.3. Cuerpo del documento
3.4. Documentos bien formados y documentos vlidos
3.5. El procesado XML
3.6. Espacios de nombres XML
3.7. Los tems de informacin en XML


En este captulo se pretenden dar las bases para la elaboracin de documentos
XML, resumiendo las tres Recomendaciones W3C ms bsicas, que estn muy
ligadas entre s: XML, Espacio de Nombre y la llamada "Information Set.
2#1# $atos B marcado
En el Capitulo 1 ya se adelant la definicin de documento ;M2 como una
informacin jerarquizada, en forma de texto, que constituye un objetivo de datos
que puede ser presentado mediante una estructura de rbol, que puede estar
almacenado en un nico archivo o estar dividido en varios. Tanto su estructura
fsica como lgica tienen la capacidad de anidar sus propiedades, lo que explica
que XML organice sus documentos de forma no lineal y en mltiples piezas.
Para crear un documento XML se puede utilizar cualquier editor de texto o un
editor especializado; son cada vez ms los paquetes de software que facilitan que
sus datos puedan salvarse como tales documentos XML.
La presentacin textual de un documento XML, como en todo ML, se puede
resumir de la forma: te!to XMLC datosBmarcado# Esto significa que el texto
de un documento XML consta de dos conjuntos disjuntos: marcado y datos. El
marcado corresponde a las instrucciones que el analizador XML debe procesar
42
(que se incluyen entre los parntesis angulares) mientras que los datos son el
texto entre la marca o eti(ueta delimitada, en inicio y final por parntesis
angulares. El procesador, una vez determinado que todos los caracteres de un
documento son aceptables, los diferentes entre texto de marcado y caracteres de
datos (CDATA).
Es importante resear que desde el principio debe distinguirse entre datos
anali4a*les (Parsed Carcter Data o PCDATA) y no anali4a*les, y que su mezcla,
en principio, no es un problema para XML, ya que admite esta posibilidad sin
problema alguno, de la misma forma que en un texto en castellano se debe
incluir un texto ingls, siempre que se seale adecuadamente. XML acta a modo
de cemento que mantiene, de forma autocoherente, los distintos archivos que
pueden ser invocados a lo largo de un documento.
El marcado en XML est constituido por:
- Etiquetas.
- Comentarios
- Instrucciones de proceso.
- Referencia a entidades.
- Referencia a caracteres.
- Delimitadores de secciones CDATA.
- Declaraciones del tipo de documento.
Mientras que el resto de caracteres son datos, entre los que se distinguen:
- caracteres Unicode
- caracteres blancos (espacios en blanco, retornos de carro y avances de lnea).
Los caracteres de datos correspondientes a todo lo que no es marcado. La secuencia
es: un inicio < >, seguido de una finalizacin < / > (la nica excepcin son las
referencias a entidades que, como veremos, comienza con el carcter "&; y
terminan con el carcter ";). Ntese que, aunque en una primera aproximacin, al
usar tambin los smbolos <y>, la sintaxis de las DTD y de XML suenen parecidas,
en realidad son muy distintas pues las DTDs ni siquiera usan etiquetas de inicio y
final.
Dado el documento XML siguiente que designaremos inicio#!ml (aunque no sea
un requisito, los documentos XML suelen almacenarse en archivos de texto con la
expresin #!ml):
<?xml version =1.0?>
<!- Introduccin a las etiquetas de XML ->
43
<miCurso>
<curso>Curso de XML! </curso>
</miCurso>
Las etiquetas DcursoE y D6cursoE son textos de marcado, mientras que el texto
FCurso de XMLG son caracteres de datos, y los caracteres que estn entre las
etiquetas <!- - y - - > corresponden a comentarios opcionales aclarativos.
Los documentos XML tienen una estructura fija, compuesta por un prlogo y un
cuerpo. En el prlogo se especifican las caractersticas del documento en s, como la
versin de XML a la cual pertenece la especificacin del tipo o estructura al cual debe
ajustarse para ser vlido, mientras que en el cuerpo se incluye la informacin
propiamente dicha, formada por el contenido en s del documento.
2#,# Prlo'o de un documento XML
El prlogo aparece al inicio del documento y consiste en la declaracin propia de un
documento XML y en su caso de las declaraciones de las DTDs o Esquemas XML
manejados en l.
2#,#1# La declaracin !ml
Todo el documento XML debe comenzar con un encabezado, que en su forma ms
simple se presenta como: <?xml.?>, normalmente requiere la identificacin de la
versin de XML a la cual se ajusta el documento . Para ello, se agrega el atributo
versin: <?xml version= "1.0 ?>
Aunque en estos momentos ya ha aparecido la versin 1.1, el uso de "1.0 es muy
general, ya a pesar de que esta declaracin sea opcional, debe usarse ya que en un
futuro, por defecto puede asumirse que un documento es de la ltima versin, con
lo que surgiran problemas y errores ahora evitables.
Este encabezado puede tener otros dos atributos optativos, el primero es
encodin' que determnale tipo de codificacin del documento, cosa bsica para la
interpretacin de los caracteres especialmente si se trata una lengua con
caractersticas especiales como sera el caso del japons. Conviene saber que en
caso de incluirse este atributo los conjuntos ms utilizados para el texto con
lenguaje espaol son el ISO-8859-1 y el UTF-8. El segundo atributo es standalone,
que indica que si se necesita un documento externo (DTD o XML Schema) para
definir la estructura de documento, con lo que adopta los valores "yes o "no; por
ejemplo:
44
<?xml version= "1.0 encoding= "ISO-8859-1 standalone= "yes ?>
2#,#,# $eclaracin del tio de $ocumento
Dejando para el prximo captulo la declaracin de los Esquemas XML, veamos la
forma de indicar en el prlogo del documento la forma como una DTD se incorpora a
l. Es la llamada declaracin del tipo de documento, que no hay que confundir con la
propia DTD que se refiere a las declaraciones de marcado que proporciona la
pseudogramtica de la DTD. Aunque sea obvio, hay que resaltar que declaracin y
definicin de tipo de documentos no son la misma cosa, de forma que la declaracin
en cualquier caso figurar dentro del propio documento, pudiendo obviamente,
aparecer una misma DTD en mltiples documentos.
Una DTD se declara en un documento XML a travs de DOCTYPE con la sintaxis:
<!DOCTYPE nom*re SYSTEM (o PUBLIC) uri:
donde nom*re y uri siguen las reglas correspondientes para dar nombre a una DTD
y para escribir un URI. A modo de ejemplo, es muy corriente encontrar
declaraciones en archivos basados en versiones recientes de HTML, tales como:
<! DOCTYPE html PUBLIC "-//W3C//DTD html 4.0 Transitional//EN>
en la que se puede distinguir sus cuatro partes:
DOCTYPE: indica que esta etiqueta contiene una DTD.
HTML: declara el nombre de la DTD.
PUBLIC: indica que la DTD es pblica y est disponible.
-//W3C//DTD HTML 4.0 Tradicional//EN: expresa el URI correspondiente (en este
caso es un documento W3C, en ingls).
La DTD invocada puede estar bien en un subconjunto interno al documento, por
tanto visible nicamente en el propio archivo del documento (obviamente si una
DTD va a ser utilizada por muchos documentos, debe colocarse en un subconjunto
externo). Recalcar que no existe ninguna dificultad en especificar al mismo tiempo
subconjuntos internos y externos, de forma que su unin acaba formando la
declaracin del tipo de documento. Como hemos indicado un documento se dice que
es independiente 3standalone6, si no se refiere a ningn subconjunto externo.
45
Las DTDs externas se determinan a travs de su URI utilizando las palabras
reservadas SYSTEM o PUBLIC segn pueda o no descargarse sin ms. De aqu que si
se usa una DTD especfica para "miMensaje se escribe:
<! DOCTYPE miMensaje SYSTEM "miDTD.dtd>
mientras que el ejemplo anterior al usar la palabra PUBLIC se indica que la Dudes
muy usada, y puede descargarse sin problemas.
Comentarios
En un documento XML, los comentarios pueden aparecer en cualquier lugar del
mismo, siempre que queden fuera de otras marcas, tal como permite la gramtica.
Estos siguen la misma sintaxis del HTML:
<!- introduccin a las etiqueta de XML ->
y aunque no formen parte de los datos, conviene saber que un procesador de XML
puede recuperar su texto.
2#2# Cuero del documento
Una vez definido el prlogo, vamos con las partes que constituyen el contenido de
un documento XML.
2#2#1# +lementos & Atributos
En XML, un elemento es un componente lgico de la jerarqua de un documento, que
a su vez se puede descomponer en otros elementos. En otras palabras, es una
estructura compuesta de una etiqueta inicial, una etiqueta final y las etiquetas y la
informacin entre las etiquetas que pueden ser un texto tal como:
<Saludos> Hola amigo</Saludo>
Todo documento XML contiene uno o ms elementos, todos ellos bien delimitados
e identificados por un nombre llamado identificador enrico, de forma que, en su
conjunto, el documento debe cumplir una serie de normas y restricciones tales como
que si la etiqueta de inicio de un elemento est en el contenido de otro elemento, su
correspondiente etiqueta final debe estar en el contenido de este mismo elemento,
46
esto es, los delimitadores de lo elementos deben estar estrictamente animados, y un
anidamiento inapropiado es un error. Por ejemplo:
<x><y>hola</x></y>
es un error, ya que el elemento & debera terminar antes que el elemento !.
El contenido del elemento es cualquier cosa contenida entre sus etiquetas de
inicio y final, y puede constar tanto de texto como de otros elementos. En el caso de
un elemento sin contenido, llamado elemento vac+o, se representan bien por la
etiqueta inicial seguida por una final, o una etiqueta de la forma <./>; por ejemplo:
<br></br> o <br/>. Las funcionalidades de estos elementos vacos son diversas,
como el caso de solapar rboles o enlazar contenidos (por ejemplo: <image file
"dibujo.jpg />)
Se llama atri*uto a la forma en que los elementos incorporan informacin
relacionada acerca de s mismos, describiendo sus prioridades, y acabando de dar
significado a los nodos que constituyen el rbol del documento. Por tanto un
elemento, adems de su identificador, puede tener un conjunto de atri*utos, cada
uno con su nombre y valor respectivo. Ms concretamente, un atri*uto ;M2 es un
componente estructural, formado por un par nom*re<valor, incluido en un elemento
al que modifica o refina, bien en su significado, bien sus caractersticas. Todo valor
de un atributo es una cadena de texto entre comillas.
Los atributos se asocian a la etiqueta de inicio del elemento donde aparece el par
nombre/valor para cada uno de ellos, de forma que un mismo atributo aparece una
sola vez en cada elemento. Su declaracin toma la forma
<Element nomAtribut1=valor nomAtribut2=val/>
En XML, existen unos pocos atributos reservados, que irn apareciendo a lo largo
del texto con la particularidad de que cualquier atributo que empiece con `xml se
reserva para el Standard XML. De ellos es importante !ml.lan' usando para
representar el lenguaje de un elemento, siguiendo el cdigo de lenguajes ISO 639, y
que adopta la forma:
<pais xml:lang=es>Chile </pais>.
<pais xml:lang=cat>Chili</pais>.

Los nombres de elementos y atributos siguen las mismas reglas, de forma que
pueden contener: caracteres alfanumricos (a-z, A-Z, 0-9), caracteres acentuados
como ., ideogramas, caracteres griegos, etc.
47
Al escribir un documento, resulta muy frecuente plantearse si se est ante un
elemento o un atributo y resolver esta duda supone determinar con cuidado la
informacin concreta que se modela en un documento para poder discernir en cada
caso. Este problema de decidir entre un elemento o un atributo es habitual en
Informtica (diferenciacin entidad/atributo en el modelo Entidad/Relacin,
diferenciacin clase/atributo en el mbito del anlisis y diseo orientado a objetos,
etc.) y en XML, aunque no haya reglas; como orientacin conviene seguir la
indicacin: "con datos usar elementos y con metadatos atributos.
2#2#,# +ntidades
En un documento ya sabemos que las entidades son las distintas unidades de
almacenamiento del contenido del mismo y muchas de las cosas dichas para ellas en
el seno de las DTD son vlidas ahora. Todas las entidades presentes en un
documento XML debe identificarse con un nombre, con las dos nicas excepciones
de la propia entidad del documento en cuestin y del subconjunto de DTDs externas
que se puedan usar. Con esta salvedad, en XML, una entidad eneral consiste en un
nombre y un valor para su uso dentro del contenido de un documento. Las entidades
en XML, al igual que ocurre con los datos, pueden ser procesa*les o no procesa*les#
El concepto de entidad no procesa*le se refiere a objetos no XML, esto es a
entidades cuyos datos el analizador XML no puede leer (datos binarios EXE, grficos
GIF, vdeos MPEG, etc.), y por ello se consideran declaraciones que el procesador no
debe intentar interpretar como si fuera texto XML. Este tipo de entidades se definen
en un documento XML mediante un subconjunto externo de la DTD.
Una entidad es procesa*le cuando al empezar a analizar un documento, el
procesador XML la conoce como tal y por tanto asocia a su nombre un valor con su
texto de reempla4amiento, que puede ser desde un carcter a un archivo que se
conoce tambin como expansin de la entidad. El resultado de este procesamiento
es la reorganizacin del documento con el texto ya reemplazado, lo que indica la
necesidad de que las entidades se manejen correctamente a la hora de ser
expandidas.
Existen situaciones en las que una entidad no puede expandirse, como el caso de
una entidad eterna que no es localizable, en cuyo caso el procesador no podr
validarla, aunque s decidir no leer todas las declaraciones, o si lo hace, no expandir
las entidades externas, siempre informando de ello a la aplicacin correspondiente.
Esto lleva al concepto de referencia de entidad no expandida, que es como se
conoce a la referencia que se crea cada vez que el procesador tiene que saltarse una
entidad externa por no poder expandirla.
48
Es el momento de recordar que las entidades paramtricas son especficas de las
DTDs, y por tanto son diferentes de las entidades generales del XML, por lo que se
usan distintas referencias reconocindose e diferentes contextos; una entidad
paramtrica y una general con el mismo nombre son entidades distintas, de forma
que una referencia a una entidad paramtrica usa los signos porcentaje (%) y punto
y coma (;) como delimitadores, mientras que las referencias a las entidades
generales procesables utilizan la conjuncin (&) y el punto y coma (;).
Si se tuviera en la DTD:
<!ENTITY dgitos "0123456789>
puede usarse en un documento XML:
<usarUnaEntidad>&dgitos;</usarUnaEntidad>
con lo que la referencia de entidad Hd)'itosI se reemplazara por:
<usarUnaEntidad>0123456789</usarUnaEntidad>
Para evitar confusiones con los caracteres especiales, XML proporciona las
llamadas entidades interadas para estos caracteres: & (HaosI) los parntesis
angular izquierdo (HltI) y derecho (H'tI), apstrofes (HaosI) y comillas (H-uotI)
para poder representarlos si fuera necesario. De esta forma si aparecieran "<>H en
un el elemento mensa3e, escribiramos:
<mensaje>HltIH'tIHamI</mensaje>
al usar estas entidades en lugar de D% E y & se evita que el procesador XML los
confunda con caracteres de marcado.
Como ejemplo, a continuacin se presenta un documento que escribe palabras en
rabe, donde cada carcter arbico se representa por una referencia de entidad para
un carcter Unicode (cada lnea que contiene referencias de entidad representa una
palabra rabe) que en trminos de nuestro alfabeto es el inicio de: :ienvenida al
mundo de Unicode#
<?xml version = "1.0.?>
<!- Demostrando Unicode ->
<bienvenida>
<tema><!- Bienvenida al mundo de Unicode ->
H>18J1IH>1KLJIH>1KL5IH>18J8IH>1K11I
H>18JKIH>1KL2IH>1KL8I
H>1KL1IH>1K1LIH>1K1KI
49
H>18M2IH>18J8IH>1KL5IH>1KL8I
</tema>
<bienvenida>
mostrndose en la pantalla de la forma:
<?xml version=1.0?>
<!-- Demostrando Unicode ->
- <bienvenida>
- <tema>
<!-Bienvenida al mundo Unicode ->
escritura en rabe
</tema>
</bienvenida>
De lo dicho hasta ahora respecto a las identidades, se observa que entre los
requisitos exigidos a un procesador XML est:
- Hacer disponible a la aplicacin, tanto los identificadores de la entidad como la
notacin correspondiente que pueda incorporar.
- No imponer ninguna restriccin en lo que ese refiere al contenido de las
entidades no procesables.
2#2#2# *nstrucciones de Proceso
La Instruccin de Proceso (IP) es un mecanismo que permite a los documentos XML
contener instrucciones especficas para las aplicaciones que los van a usar, sin que
stas formen parte de los datos del propio documento. En consecuencia el
analizador XML al detectarlas se limita a pasar esa informacin a la aplicacin que
realiza la llamada, indicndole simplemente el modo de administrar los datos del
documento.
Una IP se delimita mediante <? y ?>, aunque exista la excepcin de la
declaracin: <?xml....?> que a pesar de ir con acompaado de <?, ?> no es una IP
como sabemos. Las IPs empiezan con un identificador (acompaado de un valor)
denominado destino u o*jeto que, siguiendo las mismas reglas de los nombres de
elementos y atributos, se usa para identificar la aplicacin a la cual se dirige. En el
ejemplo que sigue, la IP se utiliza para indicar a la aplicacin que el documento se
debe mostrar con una determinada hoja de estilo:
<?xml-Stylesheet type=text/xsl ref=MyHojaDeEstilo.xsl?>
50
donde en este caso la informacin que la acompaa t&e especifica el tipo MIME de
la hoja de estilo y re(# indica el URI donde se encuentra la hoja que se utiliza.
Una IP puede aparecer en cualquier lugar de un documento siempre que queden
fuera de otra marca, aunque normalmente se coloca en el prlogo.
Es importante sealar que en el caso de que la aplicacin no las use, stas acaban
por no tener efecto alguno, por lo que pueden mantenerse en un documento, en el
caso que ste vaya a trabajar con una aplicacin distinta de la pensada, cuando fue
creado.
2#2#5# 4ecciones C$ATA
Estas secciones de datos de caracteres son complementarios al marcado, ya que
permiten que determinados datos no sean procesados por los analizadores, con lo
que pueden contener: texto, caracteres reservados (como <) y caracteres blancos.
Las secciones CDATA, que el lector ya conoce indirectamente por su uso en las
DTDs, empiezan con la cadena "<![CDATA[" y finalizan con una cadena "]]>.
Dentro de una seccin CDATA slo la cadena final se reconoce como marcado y
gracias a ello, caracteres como, < y & pueden darse en su forma literal con lo que
no se necesita utilizar los respectivos "&lt; y "&amp;. Las secciones CDATA no
pueden anidarse, y por ello en:
<![CDATA[<saludo>hola amigo</saludo>]]>
tanto <saludo> como </saludo> se reconoce como caracteres de datos y no de
marcado.
Como se habr deducido, la razn de ser de las secciones CDATA es la posibilidad
de incluir un cdigo de secuencia de comandos, que muy a menudo incluyen los
caracteres &, <, >, y ". Para ver su utilidad, el listado siguiente muestra un
documento XML que compara un texto en una seccin CDATA con caracteres de
datos especiales:
<?xml version = "1.0?>
<formula>
<usasecuencia>
Si ( velocidad &gt; 120 )
Multa por exceso de velocidad
</usasecuencia>
<sinusarsecuencia>
<![CDATA[
51
Si ( velocidad >120 )
Multa por exceso de velocidad
]>
</sinusarsecuencia>
</formula>
done el primer elemento usasecuencia muestra una condicin donde la aparicin
del smbolo >se representa por la frecuencia &gt; mientras que en el segundo
elemento sinusarsecuencia gracias al uso de CDATA se puede expresar la
condicin usando el smbolo > (mayor que), sin cambio alguno, con la comodidad y
claridad que ello supone.
2#5# $ocumentos bien (ormados & documentos v=lidos

Con lo dicho hasta aqu, y sin entrar en la definicin formal de las correspondientes
reglas de produccin en forma BCN para un documento XML (que como sabemos
estn determinadas en las recomendaciones XML de W3C) el concepto de
documento bien (ormado implica, entre otras cosas que:
- Slo contiene un elemento raz
- Todos los elementos tienen etiqueta inicial y final con nombres idnticos
- Los elementos XML no se entrecruzan por lo que estn correctamente
anidados
- Todos los valores de atributo utilizan comillas
- Un elemento no tiene dos atributos con el mismo nombre
- No aparecen en un texto del documento los caracteres: <, >, $
- Los comentarios y las IP no aparecen en etiqueta alguna
- Aparecen slo caracteres aceptados por la codificacin del documento, la cual
fue definida en el atributo encodin' del encabezado.
- Los nombres de elementos estn compuestos usando letras, nmeros y los
signos -_.:, es relevante la presencia o no de caracteres con mayscula
- Etc
52
Por lo tanto, si un documento escrito en XML no est *ien formado, no se considera
un documento XML, por lo que el analizador al detectarlo, procede a notificarlo e
interrumpe su trabajo.
Al objeto de fijar ideas veamos un ejemplo sencillo de documento bien formado en
el que aparece el marcado XML cuyos elementos estructuran el documento de forma
que el elemento raz estado contiene los elementos nombre% residente &
rovincias# Y donde adems en la tercera lnea se incluye una IP que indica que en
caso de tener que presentarlo se debe usar una hoja de estilo determinada por los
valores type="text/xsl y href="formato_estados.xsl. El listado es:
<?xml version = "1.0?>
<!- Uso de elementos y de atributos ->
<?xml: Stylesheet type = "text/xsl href = "formato_estados.xsl?>
<estado>
<nombre> Chile </nombre>
<presidente>
<nombre>Patricio </nombre>
<apellido> Alwin </apellido>
</presidente>
<provincias>
<provincia num = "1>Valdivia</provincia>
<provincia num = "2 >Osorno </provincia>
....
</provincias>
</estado>
Escribir un documento XML bien formado generalmente no es suficiente para crear
una aplicacin por sencilla que sea, ya que de alguna forma se tiene que limitar o
controlar en mayor o menor medida el tipo de dato a incorporar.
Por ejemplo: si tuviramos una aplicacin para manejar informacin de facturas en
el que apareciera algo como lo que sigue:
<factura>
<importe>5000</importe>
<cliente>Vicente Snchez</cliente>
<cliente>Maria del Carmen Canales</cliente>
<cliente>Juan Estevez</cliente>
<fecha>edad media</fecha>
</factura>
sera, por decir algo, informativamente intil. Ya que estando el documento bien
formado, presenta evidentes errores de sentido comn, como que una factura debe
53
pertenecer a un nico cliente y que una fecha debe especificarse en algn tipo de
formato del tipo da/mes/ao.
Por ello, siguiendo las enseanzas de SGML, hay que ir ms alla de lo bien formado
y validar la estructura usada, respecto a unas reglas, con el objeto de tener
asegurada tanto su integridad como su formato. Ntese que este problema no es
especfico de los documentos XML, sino que se trata de un problema muy general de
Informtica, donde no es vano se calcula que un 70% de las lnea de cdigo que se
escriben estan orientadas a comprobar la integridad de los datos, con cosas
aparentemente tan elementales como si donde se supone que hay un entero,
efectivamente lo hay, etc.
Este tema es relevante pues, como adelantamos en el Capitulo 1, la funcin del
marcado consiste tanto en describir la estructura lgica como la estructura fsica del
documento, y por ello, es obligatorio que XML proporcione un mecanismo para poder
especificar ambas, de forma que se exprese por un lado las restricciones sobre su
estructura lgica y por otro la pena identificacin de las unidades de
almacenamiento necesarias. Ante esta situacin y siguiendo la forma de proceder
utilizada en Bases de Datos para definir restricciones, en XML se recurre tambin a
archivos de definicin o es(uemas que especifican la distribucin de datos y los
contenidos que estn permitidos en un documento. Concretamente, un esquema es
una forma de especificar restricciones sintcticas al marcado al objeto de definir su
estructura. La necesidad de contar con un mecanismo como este es evidente, ya que
si se considera.
<importe>5000</importe>
el elemento imorte adems de poder validar que tiene un contenido, es necesario
asegurarse que este contenido es numrico. Por ello sin medidas apropiadas, la
expresin:
<importe>hola</importe>
se considerara aceptable y las aplicaciones que usaran un documento con este
mercado no tendra otro remedio que comprobar que el contenido de imorten
numrico, y tomar la accin apropiada si no lo fuera, con toda la laboriosidad que
ello supondra. Por ello, en el esquema que se use en XML hay que expresar de
aguna forma que el dato del elemento imorte puede ser descrito como numrico,
con lo que 8LLL quedara validado, mientras que un hola fallara. En XML si un
documento est de acuerdo con un esquema se dice que es vlido respecto a l, y
en caso contrario se declara como no vlido#
En XML existen distintas forma para describir estos esquemas, de los cuales nos
interesan dos; uno de ellos ya es conocido, las DTDs, el segundo, que se define con
54
sintaxis XML, son los Esquemas XML del W3C (usaremos Esquemas con mayscula
para diferenciarlo del concepto de "esquema que es ms amplio). Aunque a un
documento XML no se le exige que incorpore ningn esquema su uso es ms que
recomendable ya que hay que tener un mecanismo para asegurar la conformidad del
documento cuando vaya a ser intercambiado, ya que si no se especifica un
esquema, por un lado, las aplicaciones que utilicen los archivos tendrn que detectar
cul es la estructura que define al archivo y por otro lado se correr un serio riesgo
de generar inconsistencias, al carecer la aplicacin de las especificaciones que
guiaron el esquema del documento origen.
En XML, hay que distinguir entre documento vlido y documento *ien formado, en
este ltimo no existen limitaciones sobre el nmero o tipo de contenido, mientras
que en un documento vlido, adems de estar bien formado se deben respetar las
restricciones establecidas por la definicin externa de un esquema (DTD o Esquema
XML) en cuanto a cuestiones relacionadas con los elemento y atributos aceptados,
su calidad, el orden en el cual pueden aparecer, etc. Estar bien formado es un
requisito bsico, mientras que la validez es una condicin ms fuerte que no se
requiere en XML para procesar documentos. De acuerdo con ello, los procesadores
XML se dividen en validadotes y no validadotes. Ambos dan cuenta donde falla
formalmente el documento que procesan y si adems es validador, debe indicar
cualquier violacin a las restricciones impuestas a la estructura por una DTD u un
Esquema.
En cualquier caso, la decisin de rechazar o no documentos no vlidos es de la
aplicacin, no del procesador validador que se limita a informar a la aplicacin de
ello y contina el anlisis.
A continuacin se muestra un ejemplo de declaracin de documento para
inicio.xml que ahora contiene una referencia a una DTD externa (inicio#dtd):
<?xml version = "1.0?>
<!- Uso de un subconjunto externo ->
<! DOCTYPE miCurso SYSTEM "inicio.dtd>
<miCurso>
<curso>Curso de XML </curso>
</miCurso>
suponiendo que en inicio#dtd se hubiera especificado que el elemento miCurso
contiene un nico elemento hijo llamado curso, y que en documento se hubiera
omitido este elemento, como por ejemplo en:
<?xml version = "1.0?>
<!DOCTYPE miCurso SYSTEM "intro.dtd>
<!- Al elemento raz la falta el elemento hijo mensaje ->
55
<miCurso>
</miCurso>
se tendra una estructura de documento inconsistente con la DTD (sera un
documento bien formado y no vlido) y si procesramos ste cdigo tal como sta,
obtendramos un mensaje parecido a "error por ausencia de una etiqueta de cierre.
2#8# +l rocesador XML
Un documento XML por s mismo, sin una herramienta que lo abra y procese, no
tiene mucho valor, razn por la cual se requiere un software capaz de manejarlo y
aunque este es un tema trascendente, es posible entender el procesado XML sin
entrar en exceptivos detalles y por ello slo vamos a resumir la forma en la que se
realiza el procesamiento.
En primer lugar recordemos que XML admite datos anali4a*les y no anali4a*les,
cosa que es un primer requisito para el procesador ya que con el objeto de ganar
funcionalidad, un documento XML se refiere a todos los archivos en su forma original
(GIF, JPEG, MPEG, binario, etc.). En consecuencia el procesado debe actuar
manteniendo estos distintos archivos, representados en un documento, con total
autocoherencia.
Un procesador xml consiste en un mdulo de software centrado en:
- Leer documentos
- Comprobar su sintaxis
- Informar de los posibles errores
- Proporcionar acceso tanto a su contenido como a su estructura
Y todo ello con capacidad de presentar los detalles tanto a un humano como a otra
mquina.
Los principales componentes de un procesador XML son:
- Los estores, responsables de localizar los dato que van a pasar al analizador,
ya que acaba siendo necesario que algn mdulo se encargue de funciones
tales como declarar las entidades que se pueden pasar a la aplicacin y cules
no) y otra cuestiones parecidas.
56
- El anali4ador, encargado de leer el flujo de smbolos de entrada (llamados
to5ens), y emitir los smbolos de salida basndose en las reglas gramaticales
correspondientes.
- El anali4ador lxico que lee smbolos individuales y emite un smbolo por
palabra (o grupo de caracteres) basndose en un conjunto de reglas lxicas.
- El validador, en su caso, que comprueba las reglas del esquema y que incluso
puede tener la capacidad para manejar ciertas entradas inaceptables.
Su forma de trabajar puede verse como una especie de cascada de procesadores
simples que proporcionan a su salida de datos necesarios para que pueda trabajar el
mdulo siguiente, en el sentido de "pipe que se da en UNIX.
Por lo que se refiere a la especificacin de su funcionamiento, el procesador XML,
al trabajar en beneficio del mdulo aplicacin, debe preparar la informacin a
proporcionar a cada aplicacin, as como la que se espera recibir de sta. De forma
un tanto general, podemos decir que se asume que un analizador XML debe procesar
y pasar a la aplicacin todos los caracteres.
A modo de ejemplo consideremos el caso de los caracteres blancos procedentes de
un documento, que la aplicacin debe considerar bien como sinificantes (deben
preservarse completamente) o insinificantes, esto es, dependiendo de la aplicacin
pueden concentrarse en un solo carcter blanco significante o incluso desaparecer
del todo. Este proceso se llama normali4acin. Por ejemplo:
<marca>Esto es un carcter de datos</marca>
contiene tres caracteres de datos. Cuando se normalice, los cinco espacios en blanco
existentes entre "de y "datos se concentrarn en un solo significante. Se ha
tomado el ejemplo de los espacios en blanco porque cuando se escribe un
documento XML es muy habitual presentarlo indentado, estos es, con espacio en
blanco aadidos, para enfatizarla jerarqua de la estructura del documento y con ello
hacerlo ms legible.
2#K# +sacios de nombres XML
En el mundo de las bases de datos es habitual encontrarse con situaciones tales
como que un mismo nombre haga referencia a un cliente y tambin a un proveedor
de forma simultnea, y sin embargo ello no acaba siendo un inconveniente, cuando
57
potencialmente es un riesgo. La superacin de este problema reside en que estas
definiciones generalmente se utilizan en el mbito de una base de datos local, o
cuando ms en una base de datos en red en el mbito de un mismo sistema y por lo
tanto en un entorno donde estos problemas quedan debidamente controlados. Sin
embargo este tipo de simultaneidades en el uso de nombre, es un problema que se
agranda cuando se trabaja en la Web, ya que entonces los nombres dados a los
elementos son de mbito global, y por ello se impone un mecanismo que evite los
conflictos potenciales.
El uso simultneo de un mismo nombre conlleva al riesgo de que se produzcan
colisiones de nom*res, esto es, que elementos de diferentes espacios de nombres
puedan tener el mismo nombre. Por ejemplo, es posible que utilicemos el elemento
"hora para marcar datos referidos a la hora en que ocurri un incidente en la
carrera, mientras que un operador podra utilizar "hora para referirse al momento
en que debe hacer una inspeccin a un sistema, y si ambos elementos se llegaran a
utilizar en un mismo documento, se dara una colisin, al no poder distinguir qu
clase de datos contendra el elemento "hora. Para evitar estas colisiones, en XML se
recurre al uso de prefijos adecuados, de la forma:
<indicente:hora>06:33:19 </incidente:hora>
<inspeccion:hora <08:45:22 </inspeccion:hora>
Al ser uno de los objetivos de XML facilitar el intercambio de informacin, es
imprescindible que los documentos se diseen para ser compartidos, lo que explica
la constante aparicin y uso de vocabularios en las distintas aplicaciones y dominio a
la que nos referiremos en el Capitulo 10. Esta diversidad de vocabularios recalca la
importancia de tener un nico significado asumiendo que se puede combinar varios
de ellos en un mismo documento.
En XML se llama espacio de nom*res a una coleccin de nombres que proporciona
un mecanismo por el que los nombres de elementos y atributos pueden asignarse
para cada uno deseando, utilizando prefijos adecuados. Estos dominios nominales
son objeto de una recomendacin del W3C elaborada para cumplir tres objetivos:
a) Poder mezclar distintos vocabularios XML en un mismo documento.
b) Identificar unvocamente cada etiqueta XML
c) Disponer los nombres universales cuya panormica se extienda ms all del
documento que los contiene, a modo de ejemplo, los nombres de los
elementos: html, head, title, body, p, div, table, hl, etc. forma parte del
espacio de nombres XHTML mientras que: svg, rect, polyline, etc., forman
parte del espacio de nombres SVG, el lenguaje para la representacin grfica
de datos XML.
58
La idea subyacente consiste en prefijar mediante un URI los nombres en la forma
etiqueta/atributo (donde en este caso, el atributo define el espacio de nombres al
cual pertenece la etiqueta) de forma que los nombres quedan cualificados con cada
espacio de nombre identificado por medio de un URI. Llamaremos nom*res del
espacio de nom*res al correspondiente valor de la URIref, que lo identifica de forma
nica y persistente. Siguiendo el ejemplo anterior, el nombre del espacio de
nombres de XHTML es "http://www.w3.org/1999/xhtml y el de SVG,
"http://www.w3.org/2000/svg.
De forma las URIs universales, combinados con un espacio de nombres propios del
documento, permiten que un documento tenga identificadores nicos. Para
referirnos a los elementos y atributos de un espacio de nombres, se utiliza una
sintaxis de prefijo lo que selecciona, de forma que este prefijo sirve como una
especie de "Proxy para su correspondiente URIref.
Diremos que se declara un espacio de nombres, cuando se usa el atributo
reservado !mlns (!ml namespace) de la forma xmlns: prefijo= "URI; por ejemplo:
xmlns:xsl=http://www.w3.org/1999/XSL/Transform.
Por tanto una declaracin de un espacio de nombres consta de:
- Palabra clave !mlns definida por el W3C para identificar espacios de
nombres XML. Esta se separa del prefijo mediante dos puntos (:).
- Pre(i3o o nombre abreviado del espacio de nombres que se utiliza en la
declaracin de todos los elementos y atributos que pertenecen al mismo.
- $e(inicin que corresponde al URI que define el espacio de nombres de forma
exclusiva.
Aunque XML sea un metalenguaje que permite a cada autor desarrollar su propio
lenguaje de marcas para cada aplicacin, es muy importante recalcar desde el
principio que los espacios de nombres deben reutilizarse al mximo, tratando de no
reinventar nada, aunque ello suponga combinar distintos vocabularios en un mismo
documento. Esta capacidad para combinar distintos vocabularios es uno de los
aspectos ms importantes de XML ya que lo hace realmente "extensible. De aqu la
necesidad de evitar conflictos entre espacios de nombres, y de usar los vocabularios
universalmente aceptados al publicar un documento.
2#K#1# 1ombres cuali(icados
59
Para superar la dificultad que supone el hecho que la notificacin con URIref
produzca lneas bastante largas, existe una sintaxis sencilla para declarar la
asociacin del prefijo del espacio de nombres con una URIref, de forma que un
nombre se puede escribir con un prefijo asignado a un URI del espacio de nom*res,
seguido por un nom*re local. Un nombre que haga uso de la sintaxis dada por la
pareja:
Prefijo:Partelocal
se llama nom*re completo o cualificado 3=>ame6#As, por ejemplo, si el prefijo foo
se aplica a la URI del espacio de nombres: http://ejemplo.org/algunsitio, (oo.bar
abrevia la URIref: http://ejemplo.org/algunsitio/bar.
Una vez declarado un espacio de nombres en un documento, cualquier elemento
o atributo que pertenezca a l se utilizar mediante el prefijo. Veamos un ejemplo
del uso de !lmns para crear dos prefijos de espacios de nombres: te!to o ima'en:
<?xml version = "1.0?>
<texto:directorio xmlns:texto = "urn:martin:textoinfo
xmlns: image = "urn:martin:textoinfo>
<texto:archivo nombrearchivo = "libro.xml>
<texto:descripcin>Una lista de libros</texto:descripicion>
</texto.archivo>
<imagen:archivo nombrearchivo = "gracioso.jpg>
<imagen; descripcin >Un dibujo gracioso</imagen:descripcin>
<:imagen:tamao ancho = "200 largo = "100 /?
</imagen:archivo>
</texto:directorio>
donde para asegurar la unicidad de los URIs se han usado URNs, concretamente:
urn.martin.te!to*n(o & urn.martin.im'en*n(o# Como se observa se utiliza el
prefijo te!to para describir los elementos archivos y descricin y el prefijo
ima'en para los elementos archivos% descricin & tamaNo% figurando estos
prefijos tanto en las etiquetas finales como en las iniciales.
2#K#,# +sacios de nombre or de(ecto
Al objeto de que el autor del documento pueda evitarse tener que colocar
constantemente un prefijo, normalmente en ms usado se puede especificar un
espacio de nom*res por defecto para un elemento de forma que tambin se usa
para sus elementos hijos que no incorporen ningn prefijo. Se declara con un
60
atributo !mlns sin prefijo y se considera que es vlido, tanto en el elemento en el
que ha sido declarado, como en todos los elementos dentro de su contenido; por ello
en particular, para declara un espacio de nombres por defectos en todo el
documento basta con usar este atributo !mlns en el elemento raz. Con el uso de un
espacio de nombres por defecto, si no aparece ninguno, se usa ste y todos los
elementos del documento sin prefijo se tratarn como pertenencias a l; por
ejemplo:
<?xml version="1.0?>
<revista xmlns="http://www.miservidor.com/revistas>
<articulo>
<titulo>Introduccin a los Espacios de Nombres</titulo>
<autor>Vicente Perez</autor>
<cuerpo>Los espacios de nombres son simples.... .</cuerpo>
</articulo>
</revista>
Al usar un espacio de nombres por defecto, el documento no es ms claro y fcil de
leer, aunque se deben tener precauciones con ello, pues cuando el archivo se
importe o se incluya en otro documento, hay que asegurarse de que no se producen
colisiones de nombres no previstas.
Recalcar que los espacios de nombres por defecto y los que no lo sean pueden
combinarse sin problemas en un mismo documento. As, el ejemplo del apartado
anterior, declarando un espacio por defecto es equivalente a:
<?xml version = "1.0?>
<directorio xmlns = "urn:martin:textoInfo
xmlns:imagen = "urn:martin:imagenInfo>
<archivo nombrearchivo = "libro.xml>
<descripcin>Una lista de libros</tdescripcion>
</archivo>
<imagen:archivo nombrearchivo = "gracioso.jpg>
<imagen:descripcin>Un dibu3o 'racioso</imagen:descripcin>
<imagen:ancho = "200 largo = "100/>
</imagen:archivo>
</directorio>
Donde, una vez especificado el espacio de nombres po defecto (correspondiente al
prefijo te!to anterior), los correspondientes elementos hijos no precisan prefijo y
por ello, lo elementos archivo y descricin en su aparicin sin prefijo estn en el
espacio correspondiente al URI urn.martin.te!to*n(o. No obstante, cuando
archivo usa el prefijo ima'en se indica que l y sus hijos estn en el espacio de
nombres del URI urn.martin.ima'en*n(o#
61
2#K#2# Los esacios de nombres & la e!tensibilidad de un len'ua3e XML
El papel que juegan de espacios de nombres en el seno de XML es ms clave de lo
que aparentan, pues XML basa su condicin de metalenguaje en posibilidad la
creacin de nuevos lenguajes, gracias a la capacidad de autodescripcin que
presenta el marcado. Cuando se crean nuevos lenguajes hay que asumir que stos
inevitablemente van a evolucionar (aadiendo, quitando y modificando alguno de su
componente) en respuesta de las nuevas necesidades y circunstancias que el uso de
toda aplicacin conlleva. Ello dar lugar a la aparicin de distintas versiones de un
mismo lenguaje que deben ser compatibles con las anteriores.
Resaltemos que el proceso de conseguir nuevas versiones de un lenguaje,
compatible con las anteriores, es uno de los problemas ms difciles y con fracaso
ms sonados en la historia de la informtica. Posiblemente una de las razones que
expliquen el xito de la Web resida en que su evolucin y la consiguiente aparicin
de nuevas versiones siempre se han hecho con los encabezamientos propios de
HTML y HTTP y ambos tiene la capacidad de proporcionar las bases y reglas para su
extensin explcita, incluso de forma descentralizada. En este sentido uno de los
ejemplos ms significativos los constituye la forma como se aadi a HTML, la
etiqueta IMG a instancias del equipo que desarroll el navegador Mosaic.
Un requisito fundamental para tener la posibilidad de extender o restringir un
lenguaje XML reside en la capacidad que se tenga para determinar los elementos y
atributos que le corresponden, y para ello el papel de los espacios de nombres
resulta clave, pues proporcionan un mecanismo para asociar en cada momento un
URI al nombre de un elemento o atributo XML especificando y en consecuencia
garantizando el significado del nombre en el marco de un lenguaje concreto.
Obsrvese que el propio HTML carece de esta capacidad para distinguir entre
distintas etiquetas que procedan de extensiones del lenguaje. Ello significa que los
autores corren el riesgo de no saber qu interpretacin va a ser aplicable en cada
momento de un mismo nombre. De hecho, en esta flexibilidad reside una de las
razones ms decisivas para pasar del HTML al vocabulario XML de HTML, constituido
por XHTML (vase ltimo captulo).
Aclaremos que los espacios de nombre junto al uso de los Esquemas XML permiten
controlar la extensibilidad de un lenguaje, ya que ayudan a conjugar la flexibilidad y
la compatibilidad con versiones previas. Ello asegura la eficiencia de XML como
metalenguaje que acaba soportando no slo vocabularios muy distintos, sino
tambin las sucesivas versiones y extensiones de los mismos que puedan aparecer
en cualquier momento.
62
2#J# Los tems de *n(ormacin en XML
Una vez introducidos los elementos bsicos de XML, conviene considerarlos con un
mayor nivel de abstraccin para poder acabar de entender el tipo de datos que
manejamos en XML. Para ello, al nivel de conjunto abstracto de datos, W3C ha
especificado, en forma de recomendacin, el llamado XML *n(ormation 4et
O*n(oset@% cuyo objetivo es proporcionar un conjunto consistente de definiciones
que sirva como referencia para todo proceso que tenga que ver con un documento
XML. Su utilidad reside por un lado de servir de basa para las especificaciones de las
tecnologas y aplicaciones XML, y por otro en definir el conjunto mnimo de
informaciones que devuelve un procesador XML.
De acuerdo con Infoset, la informacin de un documento XML consiste en una
serie de )tems de in(ormacin, donde cada uno constituye una descripcin
abstracta de una parte de un documento XML, a su vez, cada uno de estos "tems
tiene asociado un llamado con3unto de roiedades, que tambin queda
especificado en Infoset. Aunque no vamos a profundizar en este proceso de
abstraccin, s conviene recalcar sus puntos ms significativos, aunque sea de forma
breve.
Si se tiene en cuenta que tanto las notaciones como las entidades no analizables
declaradas en las DTD son conceptos que por s mismos constituyen una pieza de
informacin, Infoset concluye (cosa con la que se puede coincidir con los que hemos
visto aqu) que para describir las distintas informaciones expresadas a partir de un
documento XML existe un conjunto bsico sobre el cual trabaja XML y ms
concretamente, que existen exactamente 11 tems o piezas de informacin. La
relacin de estas piezas de informacin que constituyen un documento XML, dado
por orden alfabtico, es la siguiente:
- Atributo
- Carcter
- Comentario
- Declaracin de tipo de documentos
- Documento Entidad no analizable (o no procesable)
- Elemento
- Espacio de nombres
- Instruccin de proceso
- Notacin
- Referencia a entidad no expandida
63
Es importante que el lector se quede con la idea que este conjunto de 11 piezas o
"tems constituye, ms alla de cualquier problema sintctico, la base para
aproximarse en forma abstracta al concepto de documento XML y no debe
extraarse por el hecho de que en esta relacin no aparezcan la totalidad de
conceptos presentados hasta ahora, como por ejemplo los modelos de contenido de
los elementos de una DTD o el nombre del tipo de documento. Lo que interesa de la
anterior relacin es conocer con exactitud las piezas de un documento XML que son
decisivas en la base de anlisis. Debe quedar claro que como estructura de datos
abstracta, el "Infoset correspondiente a un documento debe ser consistente y as
las propiedades de un elemento (en la perspectiva de los espacios de nombres) debe
ser consistente con las propiedades (atributos del espacio de nombres) que
incorporen los elementos presentes en l, as como las de sus descendientes.
Gracias a esta depuracin de las piezas bsicas, XML y todos los lenguajes
derivados a partir de l estn en condiciones de tener controlado los componentes
bsicos de cualquier documento que especifiquen. Con el nico objetivo de presentar
los conceptos que maneja "Infoset, consideramos el siguiente procedente
textualmente de la propia Recomendacin de W3C:
<?xml version="1.0?>
<msj:mensaje doc:fecha="20050421
xmlns:doc="http://doc.ejemplo.org/namespaces/doc"
xmlns:msj="http://mensaje.ejemplo.org/
Telefono de casa!
</msj:mensaje>
donde se observa que su "Infoset correspondiente contiene los siguientes "tems de
informacin:
- Un documento
- Un elemento con espacio de nombres: "http://mensaje.ejemplo.org/, una
parte local mensa3e, y un prefijo ms3.
- Un atributo con un valor normalizado "20050421 y con espacio de nombres:
"http://doc.ejemplo.org/namespaces/doc", una parte local (echa y un prefijo
doc.
- Tres espacios de nombres: http://www.w3.org/XML/1998/namespace,
http://doc.ejemplo.org/namespace/doc, y http://mensaje.ejemplo.org/.

- Dos atributos para los espacios de nombre
- 11 caracteres distintos
64

65
5 Ca)tulo
+s-uemas XML




5#1# *ntroduccin

Aunque el concepto de DTD forma parte de la Recomendacin XML, hay que resaltar
que una Dadse restringe a describir la estructura del documento, presentando
importantes limitaciones a la hora de definir el contenido permitido de los
elementos, para lo que se basa prcticamente slo en el uso de PCDATA. Para
comprobar la necesidad de llegar a concretar ms la estructura de un documento, de
lo que hace una DTD, supngase que en un documento relacionado con geografa se
quiere usar el elemento locali7acin y que por razones fciles de entender, se
requiere que para que sea vlido deba cumplir condiciones como las siguientes:
1. Estar compuesto por: latitud, longitud y un error asociado a la medida
2. Los elementos latitud y longitud debe tener seis cifras decimales y unos rangos
respectivos de,-90 a +90, y -180 a +180.
3. El error de la localizacin debe ser un entero no negativo.
Si se consiguen especificar estas condiciones, los valores de los componentes de
localizacin podrn ser tales como:
66
4.1. Introduccin
4.2. Concepto de Esquemas XML
4.3. Espacio de nombres en Esquemas
4.4. Estructuras de datos en Esquenas
4.5. Elementos y atributos en Esquemas
4.6. Tipos complejos
4.7. Completar el documento Esquema
4.8. Construccin de Esquemas con Documentos mltiples
4.9. Esquemas vs. DTD

<localizacin>
<latitud>32.904237</latitud>
<longitud>73.620290</longitud>
<incertidumbre unidad="metros>2</incertidumbre>
</localizacin>
Para asegurar que restricciones como las del ejemplo se cumplen, es importante
contar con un mecanismo que asegure la validez de los correspondientes valores,
algo que una DTD no puede hacer. Por ello y con el objetivo de superar estas
carencias surgi la idea de generalizar las DTDs utilizando la propia sintaxis XML a la
hora de definir y validar las caractersticas de un documento. Aunque en la
bibliografa actual haya otras opciones (como RelaxNG) los Esquemas XML son la
alternativa seguida por W3C para superar la funcin de las DTDs y sobre la que
trabajan los desarrollos actuales, lo que significa que en estos momentos son
multitud los Esquemas XML utilizados en los ms diversos campos.
Por tanto, para validar un documento XML se recurre a todos los documentos
llamados Esquemas XML; la idea perseguida es contar con un vocabulario XML que
permita expresar las reglas que estructuran lo documentos XML utilizados en una
tarea determinada, de forma que a partir de los Esquemas se pueden definir unos
documentos instancia que usen este vocabulario. Por ello, la aproximacin de los
Esquemas dentro de la prctica del XML es doble:
- La mejora de las funcionalidades de las DTD proporcionando un nuevo mtodo
de validacin.
- La abstraccin de la estructura de un documento determinado ya existente, al
objeto de poder aplicar esta misma estructura a otros documentos, que se
convertirn en documentos instancia del documento Esquema.
En consecuencia, un Esquema especifica una clase de documentos, que interesa
tener bien especificados dentro de una determinada tarea, con el objetivo de poder
obtener "documentos instancias o formularios ajustados a la aplicacin; ello
significa especificar tanto la estructura de los documentos instancia como el tipo de
dato de cada elemento/atributo, de forma que por un lado, se dicen cosas del tipo
"este elemento contiene tales subelementos, que a su vez contiene estos otros,
etc., y otras del tipo "este elemento es un entero cuyo rango va de -90 a +90.
Los requisitos perseguidos por los Esquemas son:
a) Usar la sintaxis XML y como tales documentos XML, ajustarse a su vez a las
DTDs que describen la estructura de un Esquema, estando obviamente estas
DTDs ligadas al analizador que vlida Esquemas.
67
b) Disponer, a la hora de elaborar determinados documentos, de un documento
XML que evoque a un Esquema que interesa declarando al nuevo documento
como "vlido si est de acuerdo con el Esquema y en caso contrario el
analizador que lo declare no vlido, como si se trabajara con una DTD.
c) Tener la mxima libertad para soportar tipos de datos a la hora de especificar
elementos y atributos. adelantemos que mientras una DTD soporta 10 tipos de
datos, los Esquemas tiene predefinidos 44 y lo que es ms importante,
capacidad para derivar todos los que se puedan necesitar.
d) Recurrir y utilizar espacios de nombres, cosa no posible en una DTD.
e) Tener la posibilidad de crecimiento de los documentos Esquemas a medida que
se tengan que modificar distintos aspectos.
f) Mxima flexibilidad para poder acceder a ellos desde la Web.
En la actualidad son muchas las organizaciones e individuos dedicados a la creacin
de Esquemas para un gran nmero de sectores: financiero, cientfico-mdico,
edicin, etc.
5#1#1# $e una $T$ a un +s-uema
Al nico objetivo de introducir la evolucin desde una DTD a un Esquema,
consideremos un ejemplo de DTD, que identifiquemos por librer)a#dtd:
<!ELEMENT Librera (Libro+)>
<!ELEMENT Libro (Titulo, Autor, Fecha, ISBN, Editorial)>
<!ELEMENT Titulo (#PCDATA)>
<!ELEMENT Autor (#PCDATA)>
<!ELEMENT Fecha (#PCDATA)>
<!ELEMENT ISBN (#PCDATA)>
<!ELEMENT Editorial (#PCDATA)>
A partir de ella veamos su correspondiente sintaxis como Esquema:
librer)a#dtd. Como se observa aparece un prlogo como en todo documento XML y
a continuacin los elementos XML equivalentes a los distintos elementos de
librer)a#dtd:
<?xml version="1.0 encoding="UTF-8?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.libros.org
68
xmlns:"http://www.libros.org
elementFormDefault="qualified>
<xsd:element name="Libreria>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="Libro " minOccurs=1 maxOccurs="unbounded/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Equivale a <!ELEMENT Libreria (Libro)>
<xsd:element name="Libro>
<xsd:complexType>
Dxsd:sequence>
<xsd:element ref="Titulo minOccurs="1 maxOccurs="1/>
<xsd:element ref="Autor minOccurs="1 maxOccurs="1/>
<xsd:element ref="Fecha minOccurs="1 maxOccurs="1/>
<xsd:element ref="ISBN minOccurs="1 maxOccurs="1/>
<xsd:element ref="Editorial minOccurs="1 maxOccurs="1/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Equivale a <!ELEMENT Libro (Titulo, Autor, Fecha, ISBN, Editorial)>
<xsd:element name="Titulo Type="xsd:string/>
Equivale a <!ELEMENT Titulo (#PCDATA)>
<xsd:element name="Autor Type="xsd:string/)
Equivale a <!ELEMENT Autor (#PCDATA)
<xsd:element name="Fecha Type="xsd:string/>
Equivale a <!ELEMENT Fecha (#PCDATA)>
<xsd:element name="ISBN Type="xsd:string/>
69
Equivale a <!ELEMENT ISBN (#PCDATA)>
<xsd:element name="Editorial Type="xsd:string/>
Equivale a <!ELEMENT Editorial (#PCDATA)>
</xsd:schema>
5#1#,# $e un documento XML a un +s-uema
Los Esquemas se elaboran con el objetivo de obtener un patrn y ello muchas veces
se hace a partir de un documento XML ya usado y probado, con el objetivo de tratar
de definirlo con la mxima generalidad para que otros documentos se adapten al
Esquema obtenido y el documento que ha servido de muestra acabe siendo una
instancia del Esquema obtenido. Supngase el documento XML miatlas#!ml% a
partir del cual se pretende definir un Esquema del que sea una instancia, cuyo
contenido sea:
<?xml version="1.0 encoding="ISO-8859-1"?>
<Atlas>
<Paris>
<Nombre>Colombia</Nombre>
<Capital>Santa Fe de Bogota </Capital>
<Poblacin>450000000</Poblacin>
<Extensin>1141748 </Extensin>
</Pais>
<Pais>
<Nombre>Chile</Nombre>
<Capital>Santiago </Capital>
<Poblacin>18000000</Poblacin>
<Extensin>4000</Extensin>
</Pais>
<Pais>
<Nombre>Francia</Nombre>
..... #
</Pais>
..... # #
</Atlas>
Las DTD correspondiente a este documento es:
70
<!ELEMENT Atlas (Pais)>
<!ELEMENT Pais (Nombre, Capital, Poblacin, Extensin)>
<!ELEMENT Nombre (#PCDATA)>
<!ELEMENT Capital (#PCDATA)>
<!ELEMENT Poblacin (#PCDATA)>
<!ELEMENT Extensin (#PCDATA)>
y el resultado de generalizar miatlas#!ml a un Esquema XML (atlas#!sd):
<?xml version="1.0 encoding="UTF-8?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified>
<xs:element name="Atlas>
<xs:complexType>
<xs:sequence>
<xs:element ref="Pais minOccurs="1 maxOccurs="unbounded/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Pais>
<xs:complexType>
<xs:sequence>
<xs:element ref="Nombre/>
<xs:element ref="Capital/>
<xs:element ref="Poblacin/>
<xs:element ref="Extensin minOccurs="0/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Nombre Type="xs:string />
<xs:element name="Capital Type="xs:string />
<xs:element name="Poblacin Type="xs:int />
<xs:element name="Extension Type="xs:int />
</xs:schema>
Adelantemos que para usar este Esquema atlas#!sd dentro de documento inicial
miatlas#!ml habra que modificar su prlogo para referenciarlo adecuadamente, de
forma que ahora sus primeras sentencias sera de la forma:
<?xml version="1.0?>
<Atlas xmlns ="http://www.miatlas.otg
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation="http://www.atlas.org/atlas.xsd>
71
5#,# Conceto de +s-uemas XML
Los dos ejemplos introductorios vistos en la seccin anterior adelantan
caractersticas propias de los documentos que manejan Esquemas XML y que vamos
a enumerar ahora:
- Su elemento raz es schema, que incorpora distintos espacios de nombres y
atributos, de forma que los elementos y tipos de datos usados pertenecen al
espacio de nombres declarado en:
xmlns:xsd=http://www.w3.org/2001/XMLSchema, cuyo prefijo es xsd (XML
4chema $efinition), aunque tambin se suele usar xd.
- Por medio de tar'et1amesace se indican los elementos especficos de un
determinado espacio de nombres usado por el Esquema, pudindose usar un
espacio de nombres por defecto.
- Con el uso de Esquemas se produce un doble proceso de validacin: un
documento XML se valida respecto al esquema y ste a su vez es un
documento que se valida de acuerdo a las reglas del analizador de Esquemas.
- Los elementos para declarar elementos y atributos son element y attribute.
Como veremos, con la excepcin de los llamados componente annimos, estos
elementos y atributos tienen al menos un nombre y un tipo de dato
debidamente definidos. Cada +L+M+1T de la DTD pasa a ser un elemento
element en el Esquema y en analoga con los elementos de una DTD, se usa
el tiempo element de la forma:
<xsd:element name="nombre type="tipo/>.
5#,#1 $eclaraciones & $e(iniciones
Es importante sealar que en el Esquema XML las declaraciones de elementos,
atributos, etc. y la definicin de los tipos de datos no se diferencian entre ellos, de
forma que para definir la estructura y tipos de datos que soporta cada documento
instancia, se usan los elementos simleT&e (contiene slo datos y ningn
elemento hijo) y comle!T&e (contiene adems elemento hijo y atributos).
Dicho lo anterior, un Esquema es un documento XML que incorpora
declaraciones y de(iniciones% de forma que se declaran los elementos y atributos
que se van a representar en el documento instancia, y se definen los componentes
72
que van a ser objetivo de uso y no de representacin, como son los tipos de datos.
Una vez declarados, los elementos y atributos puedan ser objeto de referencia
dentro de distintos contextos y mbitos, para lo que sus nombres respectivos son
bsicos y de esta forma, los documentos instancia pueden referenciarlos todas las
veces que los necesiten.
As, si se tiene un elemento de nombre `numerotelefeno con un dato cadena:
<xsd:element name="numerotelefono type="xsd:string>

cada vez que se quiera referenciar este elemento se recurre al atributo re( de
element y se escribe:
<xsd:element ref="numerotelefono />.
Puesto que en un documento instancia todo elemento o atributo declara ser
instancia de un determinado tipo, el elemento numerotele(ono ya tiene nombres y
tipo, de forma que al referenciar "numerotelefono en el documento de instancia,
ste reclama automticamente que es una instancia de l, con lo que se puede
escribir sin problemas:
<numerotelefono> 963 635 589</numerotelefono>.
5#,#,# /lobal vs# Local
En un Esquema, los elementos, los atributos y la mayora de sus componentes
pueden ser globales o slo estar referidos a otros componentes del mismo, por ello
se habla de panormica 'lobal, (se puede referenciar en cualquier sitio del
Esquema) o local (su uso queda limitado a una parte del contenido del Esquema).
Un componente global puede referenciar a componentes globales de uno o ms
espacios de nombres y utilizarse en cualquier documento instancia del Esquema,
cosa que no tiene sentido en el caso local.
Slo son elementos y atributos globales los que son hijos del elemento raz
schema, y en consecuencia, su referencia en el documento instancia aparece en el
nivel superior.
Dos consecuencias de la diferencia entre la panormica global y local son:
a) Las declaraciones globales no pueden contener referencias, y por ello deben
identificar directamente tanto tipos simples como tipos complejos (como
73
veremos ello significa que las declaraciones globales no pueden contener el
atributo re( y deben usar el atributo t&e).
b) Las restricciones de cardinalidad slo pueden estar en las declaraciones locales,
ya que en una perspectiva global, el nmero de apariciones es obviamente
incontrolable.
A efectos prcticos, la distincin principal entre componentes globales y locales
radica en que slo los primeros pueden reverenciarse (o rehusarse) con lo que un
elemento o atributo local acaba siendo invisible para el resto del Esquema y para
otros Esquemas, y en cada caso hay que decidir en funcin de esta caracterstica
para recurrir a una u otra panormica.
5#2# +sacios de nombres en +s-uemas
Una diferencia importante entre las DTDs y Esquemas reside en stas, como tales
documentos XML, pueden usar vocabularios asociados a espacios de nombres, con lo
que le abre la posibilidad demarcar la diferencia entre elementos que compartan el
mismo nombre, pero no los mismos significados y viceversa.
Considrese el recurso cdigo postal, que en Chile es de la forma ddddddd (d
representa un dgito), mientras que en Estados Unidos es: CC-ddddd (donde CC
identifica el Estado); ambos obedecen a un mismo concepto pero presentan distintos
contenidos. Para superar este problema hay que proporcionar un espacio de nombre
para cada pas y asociarle un prefijo a cada uno de ellos. Gracias a que un Esquema
puede verse tanto como una coleccin de definiciones de tipo, como de
declaraciones de elementos, se tiene la posibilidad de indicar a qu espacio de
nombres particular pertenecen los nombres que se vayan a usar, lo que permite
distinguir entre definiciones y declaraciones pertenecientes a diferentes
vocabularios. As, con el uso de los espacios de nombres distintos, se puede
distinguir entre los cdigos postales, ya que para resolver el problema planteado
basta con una declaracin para el cdigo de cada pais concreto que se vaya a utilizar
en cada documento instancia. En otras palabras bastar con cambiar el espacio de
nombres para mantener la validez de la aplicacin con la que se trabaja.
5#2#1# Pael de los +sacios de 1ombres
En un Esquema aparece una diversidad de espacios de nombres, con funciones
distintas en cada caso; en el primer ejemplo, se observa que en atlas#!sd aparecen
los siguientes:
74
- !mlns.!sdChtt.66PPP#P2#or'6,LL16XML4chema. indica que los
elementos y tipos de datos usados (schema, element, complextype, sequence,
string, bolean, integer)provienen del espacio de nombre
http://.../XMLSchema.
- tar'et1amesaceChtt.66PPP#atlas#or'. indica que los elementos
definidos en este Esquema concreto (Atlas, Pais, Nombre, Capital, Poblacin,
Extensin) pertenecen al espacio de nombres indicado que llamaremos de
destino (tar'et), y que obviamente se pasa al documento instancia para su
uso correspondiente.
- !mlnsChtt.66PPP#atlas#or'. indica el espacio de nombre por defecto del
Esquema, que ser: http:www.atlas.org, de forme que cuando aparece una
referencia como re(C"Pais sin ningn prefijo, se sabe que se refiere a la
declaracin del elemento Pais en este espacio de nombres.
Por su parte, en lo que se refiere al documento instancia miatlas#!ml se observa,
que adems del espacio de nombres indicado por tar'et1amesace, aparece la
declaracin "!mlns.!siCQhtt.66PPP#P2#or'6,LL16XML4chemaRinstanceS
que se encarga de pasar del espacio de nombres del Esquema al espacio de
nombres de la instancia, o dicho en otras palabras, relacione el documento instancia
con su correspondiente Esquema.
Por tanto existen espacios de nombre con distintos contenidos:
a) El que define los Esquemas
(xmlns:xsd:http://www.w3.org/2001/XMLSchema).
b) El (los) de destino (targetNamespace) especfico(s) del esquema construido al
que se refieren los correspondientes documentos instancia.
c) El "por defecto que puede ser o no uno de los dos anteriores.
d) El que permite usar el Esquema en el documento instancia.
Puesto que un Esquema opcionalmente puede especificar un espacio de nombres por
defecto, ste est implcito en cualquier referencia a un componente global que no
incluya ningn prefijo. As, si el espacio de nombres por defecto correspondiera a la
URI asociada al prefijo !sd, al usar el nombre to9en implica automticamente
referirse al nombre cualificado !sd.to9en#
75
Ntese que el espacio de nombres por defecto se aplica slo a referencias en el
Esquema, y por tanto estos defectos no tienen impacto en sus documentos
instancia. Como se ha visto en los ejemplos vistos, es habitual usar el espacio de
nombres indicado por tar'et1amesace como espacio de nombres por defecto de
la forma:
<?xml version="1.0 encoding="UTF-8?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema>
targetNamespace="http://www.miservidor.com
xmlns="http://www.miservidor.com
</xs:schema>
lo que es una buena prctica pues todas las declaraciones del Esquema sern parte
del propio espacio de nombres y no aparecern errores por conflictos de espacio de
nombres o por tratar de referenciar componentes que no estn definidos.
Adems, hay que hacer notar que el nodo raz schema especifica los atributos
elementAorm$e(ault y attributeAorm$e(ault, (que especifican como deben
aparecer los elementos en el documento instancia final) que pueden ser un-uali(ied
o -uali(ied. Con esta opcin se declara si los elementos del Esquema se importan o
no de otro espacio de nombres. En el primer caso se indica que en los documentos
instancia del Esquema se pueden usar nombres sin cualificar, mientras que en el
caso -uali(ied, todo elemento utilizado en el documento instancia debe pertenecer
a un espacio de nombres, aunque ello se haga a travs del espacio de nombre por
defecto, como ocurre en el ejemplo.
A pesar de su aparente trivialidad, una de las tareas ms importantes el construir
un Esquema XML consiste en determinar los espacios de nombre involucrados, ya
que al poder existir varios en un mismo Esquema, la forma como stos se declaren
determina la capacidad para importar o incluir nuevos Esquemas (o sus elementos)
en un documento, ya que el procesote actualizacin frecuentemente supone tener
que incluir nuevos espacios de nombres. Por otro lado, debe tenerse en cuenta que
la variedad de prefijos dificultan la comprensin de los documentos instancia, con
confusiones acerca del espacio de nombres que se aplica en cada momento, cosa
que hay que saber controlar en la prctica.
5#2#,# +sacio de nombres & documentos instancia
Cuando un determinado documento instancia se asocia con uno o ms Esquemas
durante el correspondiente proceso de validacin, es necesario identificar tanto las
declaraciones (de elemento y atributo) como las definiciones (de tipo de datos) que
van a usarse al objeto de poder contrastarlos con el Esquema que les corresponda.
76
El espacio de nombres de destino juega un papel importante en este proceso de
identificacin, ya que al definir un Esquema se dispone de un nuevo vocabulario para
uso de sus documentos instancia y en consecuencia los elementos y atributos
respectivos se identifican por este espacio de destino.
Repasemos el encabezado del documento instancia del ejemplo que estamos
manejando y que adopta la forma:
<xml version="1.0?>
<Atlas xmlns="http://www.atlas.org
xmlns :xsi="http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation="http://www.atlas.org/atlas.xsd>
donde al declarar "http://www.atlas.org sin prefijo, el resultado por defecto es
indicar al validador de Esquemas donde pertenecen los elementos usados en esta
instancia. A continuacin se dice que se usa el espacio de nombres:
"http://www.w3.org/2001/XMLSchema-instance y finalmente schema2ocation
indica que el espacio de nombres http://www.atlas.org sta definido en atlas#!sd#
Se observa que con esta combinacin de espacio de nombres, el documento
instancia no presenta ningn problema de especificacin y conviene retener este tipo
de encabezamiento a la hora de trabajar c0on documentos instancia.
5#5# +structuras de datos en +s-uemas
En XML conviven dos perspectivas distintas respecto a las estructuras de datos: por
un lado, la creacin de documentos como ejemplo de datos semiestructurados,
buscando un formato compatible con la idea tradicional de "documento, con grande
bloques de texto, tales como un libro o una carta, cuya estructura ya es conocida y
aceptada por todos, y por otro, ms especfico, la definicin de datos cuya
estructura no est estandarizada y donde cada autor de un documento debe tomar
sus decisiones. Esta ltima perspectiva es parecida a la que se da a la hora de
definir los esquemas da una base de datos, donde los "documentos contienen
piezas de informacin que se estructuran de la forma que sea ms conveniente para
cada aplicacin.
Desde la segunda visin, en informtica los tipos de datos sirven para dar un
marco en el que se comparta significado, al tiempo que se refuerza su integridad.
As, no es adecuado declarar ?echa como un simple tipo de cadena, ya que son
cualquier conjunto de caracteres. incluido los que no tengan nada que ver con una
fecha, sera aceptado como tal. Es obvia la necesidad de restringir los valores
permitidos y as se hace con ?echa: "un tipo de dato predefinido y que representa un
77
dia especfico de la forma CCAA-MM-DD, con rango para CC:00-99, para AA:00-99,
para MM:01-12 Y PARA DD:01-28 si el mes es el 2;01-29 si el mes es el 2 y GYear
(ao del calendario gregoriano) es bisiesto; 01-03 si el mes es el 4, 6, 9, o el 11 y
01-31si el mes es el 1, 3, 5, 7, 8, 10, o 12. Se notar que usando slo DTDs no se
tiene predefinido este tipo de dato, por lo que los Esquemas han tenido que
solucionar esta carencia proporcionando un mecanismo para que se pueda escribir
?echa adecuadamente.
Puesto que en XML los valores de elementos y atributos deben tener un significado
lxico, los Esquemas especifican tipos de datos, y no se quedan en asumir las
estructuras de datos bsicos utilizadas en la mayor parte de los lenguajes de
programacin. A este proceso de obtencin de nuevos tipos de datos a partir de
otros ya existentes se llama derivacin.
Considrese el ISBN de un libro consistente en nueve dgitos seguidos por otro o
por el carcter X, que debe ser una cadena restringida a: d-ddddd-ddd-d, d-
ddd,ddddd-d, d-dd-dddddd-d. Para controlar los patrones (pattern) vlidos se
recurre a la sintaxis de las expresiones regulares propias de las gramticas formales,
con lo que se puede especificar las restricciones para las tres cadenas permitidas de
la forma:
<xsd:simpleType name="tipoISBN>
<xsd:restriction base="xsd:string>
<xsd:pattern value="\d{1}-\{5}-\d{3}-\{1}/>
<xsd:pattern value="\d{1}-\{3}-\d{5}-\{1}/>
<xsd:pattern value="\d{1}-\{2}-\d{6}-\{1}/>
</xsd:restriction>
</xsd:simpleType>
De forma ms concreta, en Esquemas XML se llama tio de datos a una tripleta
ordenada cuyos valores pertenecen respectivas a:
- Un esacio de valores (cadenas en este ejemplo) para los valores del tipo de
datos especificado.
- un esacio l<!ico (la secuencia de literales del ISBN)
- Las (acetas que caracterizan las propiedades de cada espacio de valores (los
patrones descritos). En esquemas XML existen hasta 15 facetas, alguna de las
cuales son: length, minlength, maxlength, pattern, enumeration,
minInnclusive, maxInclusive, minExclusive, maxExclusiva.
78
A los elementos que contienen subelementos y/o incorporan atributos se les llama
de tio comle3o, mientras que si slo contienen nmeros, cadenas, fechas, etc. se
dice que son de tio simle de forma que los tipos complejos se derivan a partir de
tipos simples. Los elementos simleT&e y comle!T&e de esquemas XML
definen cualquier nuevo tipo de datos bien sea simple o complejo. En cuanto a los
atributos, obviamente slo tienen datos de tipo simple.
5#5#1# Tios simles
Un tipo de dato simple puede ser rede(inido (incorporado al Espacio de Nombres
de los Esquemas) o derivado (definido por el autor del Esquema). Entre los
predefinidos se distingue entre rimitivos% que coinciden con los tipos
habitualmente utilizados en Informtica y los derivados de rimitivos. Las tablas
4.1 y 4.2 muestran la relacin de datos predefinidos, primitivos y derivados de
primitivo, existentes en Esquemas XML.
TABLA 4.1. Tipos de datos simples primitivos
ejemplos de declaracin de elementos usando tipos primitivos son:
- <xs:element name="temperatura type="xs:decimal/>donde el elemento
temperatura tiene un valor decimal; por ejemplo:
<temperatura>98.6</temperatura>
- Dxs:element name="fiesta type="xs:date/> donde el elemento fiesta tiene
un valor CCYY-MM-DD; por ejemplo: <fiesta>2004-04-12</fiesta>
TABLA 4.2. Tipo de dato predefinido derivado de primitivos
Como ejemplo de uso de datos predefinidos derivados, podemos citar su uso para
manejar sucesiones de ceros y unos; por ejemplo:
<xsd:element name="cero type="xsd:unsignedByte fixed="0/>
o el uso de enteros positivos: por ejemplo:
<element name="codigopostal type="positiveInteger/>
Es el momento de recalcar que un tipo de dato en Esquemas se dice que es
atmico si es indivisible como tal dato. Por ejemplo, dado el valor de CL para Chile
definido como 1MTOT+1 (tipo de dato predefinido derivado) en un elemento Estado
79
ninguna parte del mismo, como sera el carcter "L, tiene ningn significado por s
mismo.
5#5#,# $e(inicin & derivacin de datos simles
A partir de los datos simples existe la posibilidad de obtener nuevos tipos de datos
simples, bien por definicin (listas y unin) o por derivacin (por restriccin a partir
de un tipo base utilizando las facetas correspondientes). Para definir nuevos datos
simples se usa el elemento simleT&e que constituye la representacin de un tipo
simple en un documento, identificndolo con un nombre. Los contenidos posibles de
este elemento son los elementos: list% union% y restriction# Adelantemos que
aunque los tipos simples se deriven por restriccin, en el caso de los complejos
tambin se hace por extensin.
+l elemento list: en Esquemas, se entiende por lista a una sucesin de elementos
simples delimitados por espacios en blanco. Por ejemplo:
<Elementolista> valor1 valor2 valor3</Elementolista>
Los elementos de una lista pueden ser globales locales, siempre que todos los
valores contenidos en ella sean de un mismo tipo (identificado por medio del
atributo itemT&e). Supngase que se tiene un tipo simple llamado mi+stero,
derivado de los enteros con un rango de 10000 a 99999, y a partir de l se crea la
lista:
<xsd:simpleType name="listaMiTipoEntero
<xsd:list itemType="miEntero/>
</xsd:simpleType>
con ello un valor vlido para listaMiTio+ntero puede ser:
<listaMiTipoEntero>20003 15037 95977 95945</listaMiTipoEntero>
+l elemento union. as como las listas exigen que el valor de sus miembros sean
de un mismo tipo, el elemento union crea un nuevo tipo simple permitido que el
valor de un elemento o atributo contenga una o ms instancias con tipo construidos
con la unin de mltiples tipos atmicos o listas. El principal atributo del elemento
union es memberT&es que proporciona la relacin de sus posibles globales, esto
es, su valor consiste en una lista con todos los tipos de datos que constituyen cada
union concreta, siendo las dos facetas que se aplican, attern y enumeration#
Supngase que se quiere crear un tipo para representar pases, bien por dos letras
bien por un cdigo numrico de cinco cifras. Para ello se usa el tipo UnionCodi'os
construido por un tipo atmico (1MTOT+1, donde recurriremos a un Estado como
80
ES) y un tipo lista (listaMiTipoEntero, una lista de cinco cifras), que se especifica
mediante:
<xsd:simpleType name="UnionCodigo>
<xsd:union memberType="Estado listaMiTipoEntero "/>
</xsd:simpleType>
Asumiendo que se ha declarado un elemento llamado codi'osostales del tipo
UnionCodigos, son instancias vlidas para este elemento los siguientes ejemplos:
<codigospostales>ES</codigospostales>
<codigospostales>95630 95977 95945</codigospostales>
+l elemento restriction proporciona la funcionalidad de especificar las facetas que
restringen un tipo simple ya definido, que se llama tipo *ase. Con el uso conjunto de
restriccin (para indicar el tipo de base e identificar las facetas que restringen su
rango de valores) y de simleT&e (para definir y dar nombre al nuevo tipo) se
derivan nuevos tipos simples. Este elemento especifica los valores permitidos de las
facetas del tipo base, por medio de la sintaxis:
<xsd:simpleType name= "nombre>
<xsd:restriction base= "xsd:string
<xsd:facet value= "valor/>
<xsd:facet value= "valor/>
.
</xsd:restriction>
</xsd:simpleType>
El atributo bsico de restriction obviamente es base que identifica el tipo simple
sobre el que se trabaja. As por ejemplo, sabiendo que el tipo de datos cadena tiene
seis facetas opcionales (length, minlength, maxlength, pattern, enumeration,
whitespsce) se deriva un nuevo tipo llamado `numerotelefono de la forma:
<xsd:simplesType name="NumeroTelefono>
<xsd:restriction base="xsd:string>
<xsd:length value="8/>
<xsd:pattern value="\d{3}-\d{4}/>
</xsd:restriction>
</xsd:simpleType>
donde se determina que se trabaja con una cadena de ocho caracteres, que debe
seguir el patrn: ddd-dddd, aunque en este ejemplo concreto, al usarse una
expresin es redundante el uso de la faceta de longitud de la cadena.
81
En el proceso de restriccin, el uso de la faceta enumeration es particularmente
til ya que limita el conjunto de valores distintos que pueden aparecer como valores
de cualquier tipo simple, con la obvia expresin del tipo booleano. Por ejemplo, se
puede utilizar la faceta enumeration para definir un nuevo tipo simple llamado
U4A+stado, derivado de "string, cuyos valores deben ser unas de las
abreviaciones para los estados de USA:
<xsd:simpleType name="USAEstado>
<xsd:restriction base="xsd:string>
<xsd:enumeration value="AK/>
<xsd:enumeration value="AL/>
<xsd:enumeration value="AR/>
..
</xsd:restriction>
</xsd:simpleType>
5#8# +lementos & atributos en +s-uemas
Puesto que los tipos complejos pueden integrar distintos elementos, conviene antes
de entrar en ms detalles acerca de estos tipos, ver previamente los elementos
element y attribute#
Adelantemos que ambos pueden tener valores por defecto que se declaran por
medio del atributo de(ault, aunque el defecto de este atributo presenta matices en
cada caso y que adems, el atributo (i!ed se usa tanto en las declaraciones de
elemento como de atributo para asignar unos valores predeterminados. Ntese que
el concepto de valor (i!ed y de(ault en un atributo son mutuamente excluyentes, y
es un error que una declaracin los contenga a ambos.
+l elemento element
Como se ha adelantado, los elementos que van a aparecer en un documento
instancia deben aparecer en el Esquema con un elemento element, cuyo atributo
ms significativo son:
- ma!Occurs y minOccurs: determinan el nmero mximo (mnimo) de veces
que el elemento puede aparecer en un documento instancia; obviamente, slo
se aplican a atributos de elementos de tipo local.
- name: especifica el nombre usado para referenciar un tipo de elementos tanto
en el resto del esquema como en un documento instancia.
82
- re(: hace referencia a un elemento global ya declarado. Es mutualmente
excluyente con name
- t&e: especifica el tipo de datos del elemento, con un valor nombre referido a
un tipo global, simple o complejo.
Un ejemplo de este elemento es:
<xsd:element name="algunElemento type="xs:string/>
La mayora de elementos que se usan tienen elementos locales (tanto simleT&e
como comle!T&e) o una referencia a un tipo global (simple o complejo) a travs
del atributo t&e, siendo las opciones de contenido para el elemento elemenet:
annotation, simleT&e y comle!T&e.
+l elemento attribute
En un Esquema XML los atributos se declaran por medio del elemento attribute que
a su vez tiene una serie de atributos que ponen restricciones a las propiedades de
esta declaracin, cuya panormica depende de su ubicacin dentro del Esquema
(como se sabe un atributo global debe declararse como hijo del elemento schema).
Dado el fragmento:

<xsd:schema>
<xsd:attribute name="miAtributo/>
<xsd:element name="algunElemento type ="xs:string/>
D/xsd:schema>
el atributo miAtributo es global, y puede referenciarse en cualquier elemento o
grupo de atributos del documento. En caso que se quiera declarar un atributo de
forma local, ste se coloca como hijo de la declaracin del elemento
correspondiente; por ejemplo:
<xsd:schema>
<xsd:element name="algunElemento>
<xsd:complexType>
<xsd:attribute name="miAtributo/>
</xsd:complexType>
</xsd:element>
</xsd:schema>
83
Los atributos de un elemento attribute son muy parecidos a los vistos para
element; la diferencia ms importante es que los atributos son siempre de tipo
simple. Un atributo especifico del elemento attribute es use, que da la posibilidad
de limitar el uso del atributo en un documento instancia, pudiendo tomar los
valores: ocional% rohibited% y re-uired, cuyo significados respectivos son
evidentes.
Sealar que en los atributos como norma se aplica el valor por defecto cuando los
atributos quedan determinados.
5#K# Tios comle3os
Los posibles modelos de contenido que se pueden dar en un tipo complejo, adems
del caso ovoide contener slo datos son:
- Contenido de elementos: cuando un elemento solo contiene otros
elementos, que reciben el nombre de rupo.
- Contenido mi!to: cuando un elemento tiene como valor tanto datos como
elementos hijos, siendo muy frecuente que un esquema tenga elementos con
subelementos que contengan texto. Para especificar la presencia de este
contenido se usa el atributo mi!ed (con valores cierto o falso).
- Contenido vac)o: un elemento se dice es vaco si slo contiene atributos, por
lo que para su representacin se usa un tipo complejo de tal manera que en
un contenido slo permita elementos sin que se declare ninguno de ellos, con
lo que se obtiene este contenido vaco (recalcar que el valor por defecto slo
se aplica cuando los elementos son tipos predefinidos an&T&e sin que exista
ningn contenido en el elemento.
5#K#1# /ruos de elementos
Se llama 'ruo a los distintos elementos que pueden contener un tipo complejo,
pudiendo tener un nombre determinado (representado por el elemento 'rou) o
carecer de l. Es bsico definir en el Esquema, el modo en que estos grupos deben
aparecer en el documento instancia, cosa que puede ser: en un determinado orden o
secuencia (se-uence), pudiendo el autor del documento instancia elegir alguno de
los elementos del grupo (choice), o que se d al autor total libertad, tanto respecto
al orden como a la seleccin de elementos (all).
84
+l elemento se-uence. Proporciona una representacin de un conjunto ordenado
de elementos, de forma que en el documento instancia correspondiente, los
elementos tengan el mismo orden de aparicin que en el Esquema; ntese que
puede hacer cero o muchos elementos para cada tipo, dependiendo de los valores de
minOccurs y ma!Occurs de cada elemento. Este elemento se-uence ya ha sido
utilizado en los ejemplos vistos previamente.
+l elemento choice. Proporciona un mecanismo para descubrir una seleccin
dentro de un grupo, de forma que el documento instancia contiene el elemento del
grupo especificado por el elemento choice en el Esquema. Los atributos
ma!Occurs & minOccurs permiten que el documento instancia seleccione el
nmero de elementos (por ejemplo, entre dos y cuatro). Veamos cmo expresar
distintas alternativas:
1) Una seleccin entre varias:
<xsd:element name="transporte>
<xsd:complexType>
D!sd.choiceE
Dxsd:element name="tren type="xsd:string/>
<xsd:element name="avion type="xsd:string/>
Dxsd:element name="automovil type="xsd:string/>
</!sd.choiceE
</xsd:complexType>
</xsd:element>
De forma que al ser choise equivalente a un "o exclusivos, el elemento
transorte slo puede contener uno de los tres elementos tren, avin o automvil.
2) Dar la posibilidad de repetir la opcin. Un ejemplo es una cadena de bits:
<xsd:element name="cadena-batera>
<xsd:complexType>
<!sd.choice minOccursCQLS ma!OccursCQunboundedS
<xsd:element name="cero type="xsd:unsignedByte fixed="0/>
<xsd:element name="uno type="xsd:unsignedByte fixed="1/>
<6!sd.choiceE
</xsd:complexType>
</xsd:element>
+l elemento all. Especifica un conjunto sin ordenar de un conjunto de un grupo de
elementos, de forma que cada uno de ellos puede estar presente en un documento
instancia sin ninguna restriccin respecto al orden. En el ejemplo del Atlas, al
escribir:
85
<xsd:element name="Pais maxOccurs="unbounded>
<xsd:complexType>
D!sd.allE
Dxsd:element name="Nombre type="xsd:string/>
<xsd:element name="Capital type="xsd:string/>
<xsd:element name="Poblacin type="xsd:string/>
<xsd:element name="Extension type="xsd:string/>
<6!sd.allE
</xsd:complexType>
</xsd:element>
se permite a los elementos hijos del elemento Pais puedan darse en cualquier orden
en los documentos instancia.
5#K#,# Tios comle3os. +!tensin & $erivacin

Recordando que todo tipo complejo es un tipo derivado, se nos presenta tres
posibles procesos a abordar:

- La extensin de un tipo complejo, cosa no posible en los tipos simples.
- La conversin de un tipo simple a uno complejo que incorpore atributos que no
puede tener un tipo simple.
- La conversin de un tipo complejo en un nuevo tipo complejo
Obviamente para todas estas operaciones es necesario enmarcadas en el uso del
elemento comle!T&e y vamos a ver a continuacin los elementos adicionales que
permiten llevar a cabo estos procesos propios de los tipos complejos.
+lementos an&. Se utiliza normalmente para extender en el documento instancia
un elemento ya existente. En particular el elemento an& permite al autor del
documento instancia trabajar con elementos no especificados en el Esquema. As,
por ejemplo aadiendo al elemento Pais:
<xsd:any minOccurs="0/>
se indica que al construir un documento instancia, opcionalmente, se puede
extender el contenido del mismo con cualquier elemento que sea necesario.
86
El mecanismo !sd.an&, llamado en la jerga de los Esquemas "wild card (un
trmino utilizado en tenis para referirse a la posibilidad que tiene la organizacin de
un torneo para dar acceso a l a alguien que no cumpla las condiciones generales),
controla el posible uso de elementos pertenecientes a otros espacios de nombres,
que especifica este elemento, por medio de sus valores. El uso de !sd.an& permite
extender los espacios de nombres del Esquema de una forma controlada.
Por tanto !sd.an& con su atributo namesace controla los elementos que se
pueden admitir procedentes a las extensiones de un cierto espacio de nombres, los
valores ms frecuentes de este atributo son: ##any (se puede extender el Esquema
usando un elemento de cualquier espacio de nombres) y ##targetnamespace (slo
puede extender con los elementos del tar'etnamesace que aparece en el
Esquema).
+lemento an&Attribute. Permite extender en el documento instancia aquellos
atributos no especificados por el Esquema. Puesto que un atributo es un tipo simple
para esta extensin, hay que seguir la sintaxis que se indica en los prrafos
siguientes y que tiene como objetivo que un elemento simple pueda extenderse a
uno complejo, al objeto de poder contener atributos.
+lemento simle content. Como se ha dicho, slo los modelos de contenido de
tipo complejo pueden tener atributos y para ello ocurra, inevitablemente hay que
recurrir al elemento comle!T&e si se quiere especificar un atributo a un tipo
simple. Para incorporar estos atributos vamos a presentar una forma para su
extensin directa mediante el elemento simleContent y la correspondiente
conversin a tipo complejo, cuyo resultado es un contenido sin ningn elemento
hijo, pero s con atributos.
Supngase que se quiere incorporar a un Esquema un elemento que se pueda
escribir de la forma:
<elevacin unidades="metros ">1440</elevacin>
donde se tiene un contenido simple, concretamente un entero y un atributo
unidades
Veamos su declaracin por medio del fragmento:
<xsd:element name="elevacin>
<xsd:complexType> 1
<xsd:simpleContent> 2
<xsd:extensin base="xsd:integer> 3
<xsd:attribute name="unidades type="xsd:string use="required/> 4
</xsd:extensin>
87
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
1& El elemento elevacin contienen un atributo, por lo que es necesario el uso de
<xsd:complexType>.
2& El elemento elevacin no contiene elementos hijo, por lo que tiene a pesar de
tener atributos, un contenido simple y se escribe: <xsd:simpleContent>
3& Se extiende el contenido simple (un entero)con un atributo, utilizado:
xsd:extensin base="..
de forma anloga a como lo utilizamos en la restriccin con: xsd:restriction
base=".." en el caso de tipos simples (y que obviamente tambin puede
usarse para el caso de un tipo complejo)

4& Se especifica el atributo que se incluye, al cual se le puede dar el tipo de dato
adicional que se desee.
+lemento comle!Content# Permite especificar las restricciones y extensiones que
se deseen a partir de un tipo complejo. Este elemento proporciona ms flexibilidad
que simleContent, con un uso parecido. A partir del ejemplo de los cdigos
postales, vamos a definir un tipo complejo que se adapte a la direccin postal para
Estados Unidos, asumiendo que ya tenemos definido el tipo Direccin que nos
servir de base:
<complexType name="USADireccion>
<complexContent>
<extensin base="tipo:direccion>
<sequence>
<element name="estado type="USAEstado/>
<element name="codigopostal type="positiveInteger/>
</sequence>
</extensin>
</complexType>
</complexType>
5#J# Comletar el documento +s-uema
88
Para completar en un Esquema los componentes propios de un documento XML,
falta comentar la forma como ste se refiere a los Comentarios y a las IPs. de los
documentos instancia que define.
/eneracin de los comentarios.
La informacin adicional que normalmente se incluye en un comentario debe
generalizarse necesariamente en los Esquemas, pues stos proporcionan
informacin tanto a las personas como a los mtodos de procesamiento automtico
que se ejecutan en el momento de crear los documentos instancia. Los elementos
que hacen posible esta documentacin son:
+lemento annotation# proporciona un mecanismo para documentar o anotar los
componentes de un Esquema, haciendo una funcin similar a los comentarios,
aunque dando una informacin ms completa, ya que annotation no se reduce a la
forma: <!- texto ->, sino que puede proporcionar documentacin para quien maneje
el documento como para el procesado automtico del mismo.
+lemento documentation. Consiste bien en un texto, legible por un humano, bien
en una referencia a un texto dado por un URI, siempre dentro de un elemento
annotation. Su contenido en un documento instancia no tiene limites, de forma que
un elemento annotation puede contener muchos elementos documentation y
cada uno puede presentar informacin ms o menos redundante, como sera el caso
del uso de lenguajes distintos. Sus dos atributos opcionales son source (una URI
que le procesador no valido, que representa cualquier documento considerado
relevante) y !ml.lan' (que especifica el lenguaje de la documentacin).
+lemento ain(o. Proporciona informacin a otras aplicaciones, lo que supone un
procesamiento externo al propio documento y que slo un elemento annotation
puede contener.
Llamadas a rocedimientos e!ternos. el elemento notation
En Esquemas XML existe un mecanismo para que le procesador localice programas
externos o Instrucciones de Proceso, aunque no las valide durante el proceso de
anlisis del documento instancia. Para llevar a cabo esta misin, igual que su
homlogo en los DTDs, se usa el elemento notation, que proporciona un
mecanismo para que el procesador pueda localizar un tanto programas externos o
IPs sin que se validen en el momento de analizar el documento instancia
correspondiente.
Evidentemente, debe existir un elemento notation para cada referencia externa
de acuerdo con una notacin predefinida, de forma que los atributos para cada
89
elemento notation debe especificar un nombre y un recorrido para poder obtener
las correspondientes instrucciones de procesamientos o programas externos. La
nica opcin de contenido que incorpora el elemento notation coincide con el ya
visto, elemento annotation que proporciona la informacin necesario sobre el
recurso que se invoca, cada vez que se use el elemento notation.
5#U#Construccin de +s-uemas con $ocumentos mVltiles
A medida que se amplia, por cualquier motivo (habitualmente relacionado con el
mantenimiento, la extensibilidad, la accesibilidad y la legibilidad) es aconsejable
dividir su contenido entre varios documentos, y por ello debe contarse con
mecanismos que permitan las composiciones y creaciones de Esquemas a partir de
distintos documentos, diversos entre s. Para poder proceder a esta integracin hay
que distinguir segn si el espacio de nombres de destino sobre el que actan estos
documentos sea el mismo o que no lo sea, siendo ms simple obviamente el primer
caso.
Supongamos que a la hora de construir un Esquema multas#!sd, se contara con
un Esquema previo (vias#!sd) que resolviera todas las cuestiones relacionadas con
las definiciones de las carreteras internacionales, tal como:
<schema targetNamespace="http://www.ejemplo.com/VIA
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:via="http://www.ejemplo.com/VIA>
<complexType name="carretera>
</complexType>
<complexType name="Espanacarretera>
.
</complexType>
<complexType name="PortugalCarretera>
.
</complexType>
<complexType name="UKCarretera>
.
</complexType>
.
</schema>
Resulta evidente que su incorporacin al Esquema encargado de manejar las
multas dara lugar a un Esquema multas#!sd ms potente para manejo de multas
internacionales.
90
+lemento include. Aade componentes desde otros Esquemas distintos al espacio
de nombres propios del Esquema, siempre que el espacio de nombres de destino de
los elementos incluidos y el del Esquema que los incluye sea el mismo. Podemos
escribir:
<schema targetNamespace="http://www.ejemplo.com/VIA
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:via="http://www.ejemplo.com/VIA>
<annotation>
..
</annotation>
<!-Incluye la definicin de la carretera ->
<include>
schemaLocation="http://www.ejemplo.com/schemas/vias.xsd/>
<element name="multaComprobante type="via:MultaComprobanteType/>
<element name="comentario type="string/>
<element name="conductor type="string/>
<complexType name="MultaComprobanteType>
<!- se incluye informacion de la carretera donde se ha efectuado la infraccin con
el uso de VIA ->
...
...
</schema>
donde como se observa para integrar vias#!sd en multas#!sd se ha recurrido a:
<include schemaLocation="http://www.ejemplo.com/schema/vias.xsd/>
Se observa que el defecto de include, consiste en incorporar las definiciones y
declaraciones contenidas en vias#!sd para hacerlas accesibles al espacio de
nombres del Esquema multas#!sd, siempre con el uso del espacio de nombres
comn: "http://www.ejemplo.com/VIA.
Un elemento include especifica la localizacin de un documento XML, y tiene
como opcin de contenido el ubicuo elemento annotation, Los atributos que puede
tener son:
- *d para identificar un elemento del Esquema.
- 4chemaLocation para especificar los componentes a incluir. El valor de este
atributo schemaLocation es una URI que especifica:
La localizacin de un documento Esquema
91
Un fragmento que indica una parte de un documento (va una direccin http
cuyo "content-type es application/text o text/xml).
Una expresin que apunta a un Esquema.
Si el URI resultante no correspondiera a un Esquema vlido o a un documento
apropiado, el elemento include no tiene ningn efecto, esto es, el validador ignora
todo elemento include cuyo schemaLocation no sea vlido.
Aunque en este ltimo ejemplo slo se ha incluido un documento en otro, hay que
indicar que ello es posible hacerlo con ms de uno utilizando tantos elementos
include como sean necesarios; asimismo tambin es posible incluir elementos a su
vez incluyan a otros, siempre que estos documentos anidados tengan el mismo
espacio de nombres de destino.
En este proceso de inclusin, los documentos instancia asociados a un Esquema
cuyas definiciones estn en documentos distintos slo necesitan referirse al
documento ms amplio y al espacio de nombres comn, siendo responsabilidad del
procesador intgralos debidamente.
+lemento rede(ine. Constituye un mecanismo que permite redefinir tanto tipos
(simples y complejos), como grupos de elementos y atributos, obtenidos a partir de
archivos Esquema externo al Esquema utilizado. El atributo bsico de rede(ine es
schemaLocation cuyo valor especifica un Esquema de procedencia.
Al igual que include, el elemento rede(ine requiere que los componentes
externos tengan el mismo espacio de nombres de destino que el Esquema,
pudindose redefinir tambien aquellos componentes externos que carezcan de
espacio de nombres, integrndose en todos los casos en el espacio de nombres de
destino redefinido. Si en el ejemplo anterior se usa rede(ine en multas#!sd para
modificar la definicin del tipo complejo Carretera para incluir en l el elemento
numeroWrovincias (indicando el nmero de provincias que la ciudad atraviesa
una carretera@ -ue no (i'uraba el elemento carretera de(inido es vias#!sd%
se puede escribi:
<schema targetNamespace="http://www.ejemplo.com/VIA
Xmlns="http://www.w3.org/2001/XMLSchema
Xmlns:via="http://www.ejemplo.com/VIA>
<redefine>
SchemaLocation="http://www.ejemplo.com/schemas/vias.xsd>
<!- redefinicin de carreteras ->
<complexType name="carretera>
<complexContent>
<extensin base="via:direccin>
92
<sequence>
<element name="numero_provincias type="integer/>
</sequence>
</extension>
</complexContent>
</complexType>
</redefine>
...
</schema>
+lemento imort# Proporciona un mecanismo que permite que componentes
provenientes de Esquemas, con distintos espacios de nombres de distintos, puedan
usarse conjuntamente, y por lo tanto sea posible la validacin de un documento
instancia cuyo Esquema est definido a travs de mltiples espacios de nombres.
Supongamos un Esquema !!!#!sd, que use el tipo simple xvia:KILMETROS
definido en otro Esquema con otro Espacio de Nombres de destino. Para poder
integrar KILMETROS en el Esquema !!! hay que identificar y poder utilizar el
espacio de nombres en el que ste est definido y asociarlo con su prefijo. Para ello
se usa el elemento imot que identifica el espacio de destino de KILMETROS
(http://www.ejemplo.com/VIA) y asocia su prefijo !via. Con ello el tipo puede
referenciarse como !via.T*LXM+T0O4 en cualquier definicin o declaracin del
Esquema !!!#!sd. El resultado sera:
<schema targetNamespace="http://www.ejemplo.com/xxx"
Xmlns="http://www.w3.org/2001/XMLSchema"
Xmlns:xvia="http://www.ejemplo.com /va
..
<import namespace="http://www.ejemplo.com /va/>
5#M# +s-uemas vs#$T$

La recomendacin de Esquemas XML es especialmente extensa y lo visto en este
captulo slo puede considerarse una somera introduccin a ella, sin embargo como
conclusin de lo que acabamos de exponer s se sta en condiciones de resumirla
lista de las capacidades de validacin que se pueden realizar con un esquema XML y
que una DTD no hace, o lo hace de forma menos estricta.
Podemos citar los siguientes puntos:
Tio de datos. controla los tipos de datos que pueden contener un elemento o un
atributo (bolean, flota, integer, date, time, etc.).
93
Asectos de restriccin. establece lmites para el valor de los datos (longitud,
modelo, enumeracin, intervalos con mnimo y mximo, precisin, etc.).
Cardinalidad. controla el nmero de apariciones permitidas (uno, cero o uno,
cero o ms y uno o ms)
Ocin. limita los valores a los de una lista de valores dada.
4ecuencia. define el orden en el que se pueden utilizar los elementos.
Yalores redeterminados. proporciona valores que se utilizan cuando no se
especifica ningn otro valor.
Adems de estos aspectos directamente relacionados con el proceso de validacin de
un documento, hay que incluir el hecho muy relevante de que los Esquemas
permiten la definicin de tipos de datos abstractos, los que hemos llamado tipos
complejos, con lo que ello supone acercarse sensiblemente a las estructuras de
procesamiento de la informacin que se estn utilizando en los actuales paradigmas
de programacin.
En su conjunto de uso de Esquemas XML presentan grandes ventajas respecto al
de DTDs; es la principal que se est hablando siempre en sintaxis XML. En su
conjunto, los avances citados justifican la inevitable sobrecarga que supone el uso
de la sintaxis en ocasiones aparentemente farragosa en los Esquemas.
En cualquier caso, el lector debe ser consciente de que cada vez se encontrar en
los distintos campos de aplicacin del XML con una mayor cantidad de Esquemas,
que garantizan la compatibilidad de todos los documentos que van a ser objeto de
intercambio entre los distintos agentes involucrados.

94
8 Ca)tulo
Tecnolo')as ara la locali7acin en un documento XML. XPath





W3C fue consciente desde el principio de la necesidad de contar con un modelo de
datos comn, obviamente basado en la estructura de rbol, sobre el que se pudiera
disponer de un lenguaje capaz de localizar los componentes especficos de un
documento XML. Una vez definido se podran resolver problemas aparentemente tan
diversos como:
- Manejar bases de datos de documentos, ya que al interaccionar con la
informacin que contiene cada documento se pueden efectuar la bsqueda
correspondiente al manejo de una base documental.
- Dar un marco genrico para poder referenciar, obtener y destacar fragmentos
de documentos para su posterior explotacin.
- Transformar documentos que en particular servirn para poder aplicar la
presentacin concreta deseada sobre el resultado de esta transformacin.
Se observa que todos estos objetivos tienen en comn la necesidad de resolver
correcta y eficientemente la localizacin de los componentes de un documento XML,
ya que una vez conseguido, se pueden usar otras tecnologas y aplicaciones, que
5.1. Introduccin a XPath
5.2. Conceptos bsicos de XPath
5.3. Elementos de un Trayecto de Bsqueda
5.4. Expresiones y funciones XPath
5.5. Nombres escuetos
5.6. Extender XPath: conceptos de XPath
95
permitirn alcanzar los requisitos exigidos a XML en aquellos puntos relacionados
con la posibilidad de manipular documentos.
8#1# *ntroduccin a XPath
La consecuencia de la necesidad de poder manejar los documentos XML y localizar
sus componentes en una cierta solvencia, fue que, slo un ao despues de sacar la
especificacin XML, W3C diera a conocer la primera recomendacin de XPath (XML
Path Lenguage), un lenguaje declarativo que proporciona una sintaxis y un modelo
de datos para poder localizar y distingirse a una parte de un documento dado,
incorporndole adems algunas funcionalidades propias de un lenguaje de propsito
general.
Como es conocido, una de la limitaciones que presenta HTML consistente en la
dificultad que existe a la hora de seleccionar aquellos fragmentos que en su origen
no hubieran sido especialmente destacados por el autor. En particular, ello significa
que slo se pueden enlazar aquellas partes del documento previamente marcadas al
efecto. Ello empez a ser crtico a medida que la Web creca, ya que al
incrementarse el nmero de usuarios potenciales de un determinado documento,
crece la importancia de contar con la funcionalidad de poder escoger con libertad las
partes a destacar del mismo. Un simple ejemplo para justificar lo anterior aparece al
crear cursos "on line, donde es bsico poder sealar o destacar con libertad una
porcin o segmento de texto que se maneje, pues hay que trabajar igual que en el
formato papel, donde es importante subrayar los apuntes o los libros.
Para conseguir estas funcionalidades, XPath empez abordando la posibilidad de
localizar los componentes de un documento y como veremos ms tarde Xpointer
abord la seleccin de otras partes del documento, siempre con el objetivo de poder
descartar fragmentos, en este ltimo caso tanto de un documento XML como de una
entidad externa. Estos fragmentos se acabaran denominando su*recursos, que una
vez identificados pueden a su vez ser objeto de un uso o caracterizacin especial,
como ser el caso de asignarle un hiperenlaces con la tecnologa que aporta Xlink
(una sintaxis que adems de identificar un recurso, permite que el usuario de un
documento pueda reclamar en cualquier punto en el que se desee verlo, y establecer
relaciones entre diversos documento). XPath es por tanto, un lenguaje destinado a
encaminar hacia un parte del documento y a partir de l, los procesadores Xpointer
proporcionar funcionalidades para poder desplazarse seleccionando y operar sobre l
segn se necesite.
A modo de conclusin debe retenerse que gracias XPath se est en condiciones de
poder atravesar el rbol de un documentos XML, camino de sus estructuras internas,
para un posterior procesado de las mismas, y con Xpointer se pueden seleccionar y
96
especificar los fragmentos con ms detalle, basndose en una importante gama de
posibilidades, tales como: el tipo de elementos, el valor del atributo, el contenido, la
posicin relativa, etc., de forma que el resultado que se obtenga puede usarse como
un identificador de fragmento para cualquier URIref que localice un recurso.
8#,# Concetos b=sicos de XPath
XPath como ya se ha adelantado, es un lenguaje declarativo basado en cadena de
expresiones (no basado en XML) que pueden usarse dentro de URI Y atributos XML,
y cuyo objetivo es localizar partes especificas de un documento utilizando para el
proceso de sus valores un modelo de datos del documento basado en una estructura
de rbol.

La forma de trabajar de XPath consiste en que, una vez obtenido el archivo, todo
proceso con el documento descansa en la posibilidad de acceder a cada uno de sus
componentes XML, con el objeto de que stos posteriormente puedan ser
procesados y tratados de forma diferenciada. Dado un documento, XPath sirve para
cosas tan diversas como: indicar a una hoja de estilo cmo debe procesarlo, dotarlo
de hiperenlaces, dar instrucciones acerca de cmo cargar en un navegador
determinados fragmentos de l, etc. Como consecuencia ello, se extiende que en el
diseo de XPath est incluida intencionalmente la posibilidad de que este lenguaje
pueda dar embebido en distintos lenguajes huspedes.
8#,#1# +l =rbol XPath
Al ser objetivo principal de XPath dirigirse a una parte de un documento XML, hay
que facilitar la posibilidad de moverse a travs de l, cosa que se utilizado una
estructura jerrquica en rbol, y en consecuencia, debe contar con un mecanismo
que permita al lenguaje seleccionar informacin del documento objeto del
procesamiento. XPath trata a todo documento como un rbol, de forma que siempre
cuenta con la capacidad de poder saber si un nodo de este rbol se ajusta o no a la
expresin XPath que se utilice en cada momento.
Al objeto de seleccionar partes de un documento, XPath construye internamente
un rbol de nodos llamado r*ol ;@ath (excepto las posibles declaraciones DOCTYPE
que no se representan) donde a partir de la raz, el propio documento se diversifica
a lo largo de los elementos hasta las hojas constituidas bien por valores individuales
(llamadas =tomos) tales como nmeros, cadenas, etc., o bien por referencias a
nodos de otro documento. En coherencia con ello, XPath maneja cuatro tipos de
datos: cadenas (de caracteres Unicode), nmeros (en coma flotante), valores
97
booleanos (true o false) y conjuntos de nodos que en la prctica se tratan como una
lista.
Los nodos de un rbol XPath pueden ser de siete tipos:
- Raz
- Elemento
- Atributo
- Texto
- Comentario
- Instruccin de Proceso
- Espacio de nombres
En este rbol cada nodo intermedio contiene listas ordenadas de nodos hijos, siendo
la relacin entre un nodo padre y un nodo hijo que el primero contiene al segundo;
por ello, adems del raz, slo pueden tener hijos los siguientes nodos: elemento,
comentario, texto e instruccin de proceso; mientras que los nodos atributo y los
nodos espacio de nombres se consideran que slo describen a su nodo padre, por lo
que asume que no contienen nodo alguno.
El uso del trmino "Path obedecer a que la estructura que crea XPath se inspira
en el tradicional "Aile Path o ruta de acceso utilizada en un disco duro (carpetas y
archivos), aunque es de justicia destacar que realmente la semntica de XPath sea
mucho ms parecida a la del SQL en Bases de Datos que a la de una ruta de acceso.
Como veremos, al especificar su sintaxis, XPath utiliza como expresin patrn
parta identificarlos nodos de un documento una sintaxis muy parecida a la de los
sistemas operativos. Concretamente, se usa frecuentemente la barra (/) al inicio de
la expresin, seguida de una lista con los nombre de lo elementos hijos que
describen un recorrido a travs del documento, de forma que tienen capacidad para
seleccionar los sucesivos elementos que se ajuntan al mismo.
En el sentido semntico, es importante sealar que la sintaxis de XPath tiene una
estructura similar a la de un path en Unix como por ejemplo: /urs/home/pedro/docs,
donde se hace referencia a un nico archivo docs que cuelga del conjunto de
directorios /urs/home/pedro, pero cuando una expresin anloga aparece en el
marco de XPath, presenta diferencias fundamentales respecto a la del Sistema
Operativo. Vamos a destacarlas:
- La primera consiste en que al considerar una expresin XPath tal como:
/libro/capitulo/prrafo, se hace referencia a TODOS los elementos del =rra(o
que cuelguen directamente de CUALQUIER elemento caitulo que cuelgue de
CUALQUIER elemento libro, que a su vez cuelgan del nodo raz.
98
- La segunda estriba en que XPath no devuelve los elementos que cumplen con
el patrn que representa cada expresin, sino que slo devuelve una
re(erencia, es decir, una lista de punteros a los elementos que encajan con el
patrn de localizacin. Evidentemente, esta lista resultado de la ejecucin de
la expresin puede estar vaca o contener uno o muchos nodos del rbol XPath
correspondiente.
Una vez diferenciado del tradicional "File Path, se puede decir, resumiendo el
modelo XPath (que como veremos en compartido por otros lenguajes de la familia
XML como XSLT y XQuery) que los datos XML se presenta en forma de nodos y
valores, que a su vez sirven de operando y de resultados de los operadores. Las
sentencias XPath se representan en forma de secuencias, entendiendo como tal
una coleccin de uno o ms tems, donde un )tem es un nodo o un valor atmico.
Por tanto, este modelo de datos se basa en tres bloques:
- Yalores atmicos de varios tipos, unos generales (cadenas, enteros, etc.)y
otros ms especializados como nombres cualificados o URIs.
- Zrboles cuyos nodos representa el contenido de un documento XML.
- 4ecuencias (o listas) cuyos tems son valores atmicos o referencias a nodos
en los rboles correspondientes.
De acuerdo con este modelo, cuando se tiene una expresin XPath aplicada a un
documento, su resultado no puede ser otro que una seleccin de nodos o un valor
atmico (o en el lmite una sucesin de ellos).
8#,#,# 4inta!is & 1otacin
Junto con una biblioteca de funciones que veremos, la sintaxis de XPath est
orientada tanto a definir partes del documento como a proporcionar rutas hacia los
elementos. XPath utiliza la barra (/) seguida de una lista con los nombres de los
elementos hijos, que en su conjunto describen un recorrido, a travs del documento,
de forma que selecciona los sucesivos elementos que se ajustan al recorrido
expresado por la secuencia que acta como expresin patrn para identificar los
nodos de un documento. As, dado el siguiente documento con la lista de platos
internacionales de un restaurante:
<?xml version="1.0 encoding="ISO-8859-1?>
99
<comidas>
<plato pais="Italia>
<nombre>Lassagna </nombre>
<precio>9.90</precio>
</plato>
<plato pais="Espana>
<nombre>Paella de marisco</nombre>
<precio>10.50</precio>
</plato>
<plato pais="Colombia>
<nombre>Bandeja paisa</nombre>
<precio>10.50</precio>
</plato>
<plato pais="Mexico>
...
</plato>
...
</comidas>
Cuando se escriba la secuencia: comidas6lato6recio, en el marco adecuado que
haga referencia a este documento, XPath acabar seleccionando todos los precios de
todos los platos que figuran en l.
8#,#2# Tra&ecto de bVs-ueda
En XPath se llama tra&ecto de bVs-ueda (location path6 al conjunto de nodos
sobre los que se evala una expresin XPath, que obtendr como resultado otro
conjunto de nodos, formado por aquellos que cumplen los criterios especificados en
la expresin. Para dar los nodos del trayecto, se empieza designando un punto
compuesto se empieza designando un punto concreto, llamado nodo conte!to, que
es el nodo del rbol XPath donde el documento desde el que se inicia el trayecto de
bsqueda
Tanto el concepto de nodo contexto como el de trayecto de *As(ueda son
anlogos a los utilizados en la gestin de archivos. De esta forma, en XPath, a
menos que se implique un trayecto explcitos, entiende que el trayecto de bsqueda
parte del nodo que en cada momento se ste procesando. Por ello, los trayectos de
bsqueda pueden ser a*solutos o relativos; los primeros empiezan con una barra (/)
que determina el nodo contexto, mientras que un trayecto relativo carece de ella al
inicio, y el nodo contexto pasa a depender del lugar del documento en el que se est
trabajando en el momento de invocar el trayecto de bsqueda.
100
Sea absoluto o relativo, un trayecto consiste en una serie de escalones separados
por una barra, de forma que un trayecto de bsqueda absoluta es de la forma:
6escalon6escalon6[y uno relativo adopta la frmula: escalon6escalon6[
La expresin de un trayecto se evala de izquierda a derecha. As, dado el
documento siguiente con la estructura habitual de un libro:
<Libro>
<Capitulo numero="1>
<Parrafo numero="1
Texto.
</Parrafo>
<Parrafo numero="2>
Texto
</Parrafo>
...
</Capitulo>
<Capitulo numero="2>
<Parrafo numero="1>
Texto
</Parrafo>
<Parrafo numero="2>
Texto
</Parrafo>
.##
</Capitulo>
.##
</Libro>
La expresin:6libro6caitulo6arra(o, al empezar con /, selecciona el nodo raz,
independientemente del nodo contexto de cada momento; a continuacin al leer
libro, se selecciona TODOS los elementos que cuelgan del nodo contexto (que en
este caso es nico por ser el nodo raz), al seguir y leer caitulo se seleccionan
TODOS los elementos que cuelgan del nodo contexto. Al llegar a este punto hay que
hacer notar que si se estuviera gestionando un disco sera imposible que hubiera dos
directorios con el mismo nombre colgado del mismo directorio padre, algo que sin
embargo en un documento XML es perfectamente normal, como en el ejemplo
donde son varios los hijos caitulo que cuelgan del elemento libro. Al continuar
leyendo se llega a arra(o, con lo que indica seleccionar TODOS los elementos
arra(o que cuelgan del nodo contexto (ahora caitulo) aunque haya varios nodos
conte!to.
Ante este tipo de situaciones, el programa evaluador de expresiones XPath los va
a recorrer uno por uno, siguiendo la reglas de "primero en profundidad (empezar
101
por la primera rama hasta llegar a un nodo hoja y volver para seguir por la rama
siguiente para proceder de igual forma hasta agotar todas las posibilidades), en el
sobrentendido de que mientras se evala un determinado nodo, ste es el nodo
contexto momentneo.
Como se adelant, el resultado al evaluar una expresin XPath es un conjunto de
punteros a nodos que encajan con el patrn buscado.
Aunque no es nuestro objetivo profundizar en las particularidades y detalles de la
sintaxis de XPath, ya hemos podido ver que la sintaxis habitual para tratar un rbol
incorpora una serie de abreviaciones que son muy evidentes, alguna de las cuales
vale la pena citar:
- En un trayecto de bsqueda, cuando el nodo raz es el nodo contexto, basta
con escribir /.
- Una expresin como child..Autor se abrevia como Autor (como veremos en
su momento el llamado eje child es el eje por defecto).
- El operador (//) indica que se seleccionen todos los elementos del documento
que cumplan los criterios con independencia del nivel que ocupen en el rbol;
por ejemplo
//plato
Selecciona todos los elementos plato de la lista de comida.
- El operador (|)selecciona varios recorridos; por ejemplo:
/comidas/plato/nombre | /comidas/plato/precio
Proporciona todos los elementos nombre y elementos recio de los platos del
documento.
Las abreviaturas anteriores se pueden combinar y as:
//nombre | //precio
Obtiene todos los elementos nombre & recio del documento.
/comidas/plato/nombre | //precio
Selecciona todos los elementos nombre del elemento lato del elemento comidas,
as como todos los elementos recio del documento.
102
8#2# +lementos de un tra&ecto de :Vs-ueda
En un trayecto de bsqueda de XPath se pueden distinguir tres elementos bsicos:
Ejes, Nodos y Predicados, que vamos a desarrollar brevemente. Siendo esta sintaxis
de localizacin en XPath:
Nombreeje::nodocomprobacion[predicado]
Como por ejemplo:
Child::precio[precio=9.90]
8#2#1# +3es
Los Ejes (axes) son elementos encargados de especificar en un trayecto de
bsqueda la relacin existente dentro del rbol XPath, entre los distintos nodos que
quieren seleccionarse en el trayecto, y el nodo contexto de donde se parte. El
trmino ingls axes significa, adems del plural de eje, "cercenar o "podar u
ambos conceptos seran adecuados, ya que con el eje incluido en el trayecto se
realiza una seleccin de nodos de acuerdo con el patrn, dentro del rbol o mejor
dicho, dentro del subrbol que cuelga de nodo contexto. Se observa, en los ejemplos
vistos, que el uso de la barra/ (salvo cuando ha servido para denominar el nodo
raz) determina un eje.
En XPath, tienen 13 tipos de ejes; los ms habituales son:
4el(: identifica el nodo contexto y se especifica mediante un punto (.).
Child: describe los hijos del nodo contexto, y se expresa de la forma: 6child..,
aunque como se ha indicado "child puede omitirse de un trayecto de bsqueda, al
ser el eje por defecto y as para seleccionar los ttulos de libro basta con usar:
6libro6titulo#
$escendant: selecciona cualquier nodo que sea descendiente del conjunto de
nodos contexto, expresndose de la forma: // descendant::, palabra que puede
evitarse pues siempre se asume por defecto tras //. Para seleccionar todos los
prrafos de libro, se escribe 6libro66arra(o.
103
Attribute: contiene los atributos de un determinado nodo y se abrevia usando \
como prefijo del elemento buscado; por ejemplo: 66\ais selecciona todos los
atributos con el nombre de ais, aplicado al documento de comidas internacionales.
Parent: indica el nodo padre del nodo contexto y se identifica con dos puntos
seguidos (..). As, para seleccionar los nodos que tienen algn hijo de arra(o
escribiramos: 66arra(o6##, mientras que para seleccionar los nodos caitulo que
tienen algn hijo de tipo arra(o se escribe: 66caitulo6arra(o6##
8#2#,# 1odos recomrobacin o bVs-ueda

Los nodos de comprobacin o bsqueda (node test) son los encargados de identificar
un nodo o nodos concretos dentro de un eje; su funcin dentro del trayecto de
bsqueda es que cada eje pueda determinar un tipo de nodo (llamado principal) a la
hora de efectuar la seleccin. Este nodo de comprobacin pueda indicarse bien por
nombre y por tipo.
Son los nodos ms usados:
- 1ode( ): devuelve todos los nodos de cualquier tipo. As para seleccionar
todos los nodos descendientes del tipo prrafo, se escribe: 6arra(o6nodeO@
- * (llamado Bildcard siguiendo la ya citada jerga del tenis): selecciona los
nodos principales de cada trayecto (a excepcin de los tipos: texto,
comentario e instrucciones de proceso) indicando su nivel en el rbol. As:
/comidas/plato/*
Selecciona todos los elementos hijos de todos los elementos plato.
/catalogo/*/precio
Obtiene los precios de los elementos que son nietos del elemento catlogo
/*/*/precio
Obtiene el precio de los elementos que tienen dos antecesores.
//*
Selecciona todos los elementos del documento.
104
- te!t ( ): devuelve cualquier nodo de tipo texto. As para seleccionar el texto
de todos los nodos prrafos se escribe:
//parrafo/text( )
Y para seleccionar TODO el texto que cuelga de todos los nodos tipo =rra(o.
//parrafo//text( )
8#2#2# Predicados
Los predicados (predicates) son elementos que en su trayecto de bsqueda permiten
restringir dentro del conjunto de nodos seleccionados por un eje a aquellos nodos
que cumplan una cierta condicin debidamente especificada, de forma que un
predicado especifica con mayor detalle la informacin que se requiere, permitiendo
filtrar un conjunto dado. Para la obtencin de un predicado se recurre a
identificaciones o a las funciones propias de XPath que veremos a continuacin
escritas entre corchetes ([....]). Son ejemplos de predicados:
- /comida/plato[1] selecciona el primer plato de comidas
- Comidas /plato[last()] lo hace con el ltimo (ntese que no existe la funcin
first() ya que para ello se usa un predicado como plato[1])
- /comidas/plato[precio] obtiene los elementos que tengan elementos precio.
- Comidas/plato[precio=10.50]/precio, obtiene los platos con un precio cuyo
valor sea 10.50
- //*[@num] selecciona todos los elementos que tengan el atributo num.
- //capitulo[parrafo/*[@href]] selecciona todos los captulo que tengan un
prrafo que a su vez tenga algn elemento con atributo hre(.
- /libro/capitulo[@num="1]/parrafo, escoge aquellos elementos prrafos de
todos los elementos capitulo que tengan un atributo llamado num cuyo valor
sea 1.
Es importante sealar que los predicados pueden sucederse uno a otro, cosa que
tiene el efecto de la operacin lgica "Y. As, para seleccionar todos los ca)tulos
105
que tengan un =rra(o que tenga algn elemento con atributo hre(, y a su vez
caitulo tenga el atributo ublic con valor si, se puede escribir de la forma:
//capitulo[parrafo/*[@href]][@public=`si].
Una conclusin relevante a partir de lo visto hasta aqu es que el uso tanto de
nodos de comprobacin como de los predicados pone de manifiesto que XPath es
ms que un mero mecanismo de seleccin de varios nodos a la vez, ya que como se
ha podido comprobar, este lenguaje tiene la capacidad de individualizar un nodo con
caractersticas definidas, especialmente mediante predicados incluidos dentro del
trayecto. Como se entender ello da una funcionalidad muy importante de los
desarrollos basados en XPath.
8#5# +!resiones & (unciones XPath
Tras lo expuesto, es evidente que las operaciones que se pueden realizar con XPath
son de tres categoras:
- Sobre valore atmicos
- De seleccin de nodos
- Sobre secuencias
Con estas opciones clarificadas, para completar la presentacin del lenguaje, vamos
a resumir las expresiones que estn permitidas en XPath, as como las funcione que
incorpora este lenguaje.
8#5#1# +!resiones
Las expresiones en XPath se clasifican en: numricas, de igualdad, relacionales y
booleanas:
- 1um<ricas: se usan para operar sobre nmeros: suma (+), resta (-),
multiplicacin (*), divisin (div) y resto (mod.). Es importante sealar que en
cualquier circunstancia, para la evaluacin de la expresin en la que aparezca
alguna de estas operaciones, XPath convierte cada operando a un nmero,
como paso previo a efectuar la correspondiente operacin.
- $e i'ualdad: dados dos valores en una expresin XPath se puede comprobar
su igualdad (=) o desigualdad (!=) obteniendo un cierto o falso.
106
Estas expresiones deben ser tratadas con cierto cuidado como muestra la
situacin siguiente: supongamos que el valor manejado se comprueba
respecto a un valor llamado "test, en el caso de usar la igualdad en un
conjunto de nodos, el resultado es verdadero si en este conjunto de nodos
existe algn nodo con un valor que coincida con el valor de "test; en caso que
este mismo valor se evale con una desigualdad, el resultado es verdadero si
el conjunto de nodos contiene algn nodo con un valor diferente de "test.
Como consecuencia del criterio usado, hay que observar que se produce la
paradoja de que el conjunto de nodos puede ser igual y no igual al mismo
tiempo.
- 0elaciones: se usa para comparar dos valores, segn su orden, siendo bien
conocidas las posibilidades existentes: <, <=, >, >=, donde de nuevo XPath
convierte cada operando a un nmero antes de evaluar la expresin.
- :ooleanas: las expresiones habituales son O0 y and, y tambin se puede
especificar una expresin booleana con not, como negacin de predicado. As,
para seleccionar todos los captulos que no tengan el atributo ublic, se puede
escribir:
//capitulo[not(@public)]
Todas estas expresiones se pueden enlazar entre s encerrndolas entre
parntesis, como por ejemplo:
//capitulo[ (parrafo/*[@href]) and (@public=`si)].
8#5#,# Aunciones
En XPath existe una completa biblioteca de funciones para convertir y transferir
datos, cuya razn de ser es ayudar a restringir el conjunto de nodos devueltos en
una expresin XPath. A modo de ejemplo, con el uso de la funcin osition() es
posible seleccionar:
- El segundo captulo del libro mediante el uso de: //capitulo[position()=2].
- Todos los captulos menos el ltimo: //capitulo[not)position()=last())].
- El penltimo captulo: //captulo[last()-1].
107
Las distintas funciones existentes en XPath se clasifican por el tipo de datos sobre el
que se aplican, de las cuales vamos a dar algunos ejemplos de ellas segn sea este
conjunto de datos sobre el que actan.
4obre un Con3unto de nodos
*d(). Selecciona elementos por su identidad, de la forma:
Conjunto _ nodos=id(valor).
Last(). Devuelve la posicin del ltimo nodo de la lista procesada da la forma:
Numero=last()
1ame(). Devuelve el nombre de un nodo especfico de la forma:
Cadena=name(nodo)
1amesaceRuri(). Devuelve el espacio de nombres de la URI de un nodo
especfico:
Uri=namespace-uri(nodo).
Position(). Devuelve la posicin en la lista de nodos, del nodo que se est
procesando en cada momento de la forma:
Numero=position().
4obre cadenas
Concat(). Devuelve la concatenacin de todos los argumentos sobre los que actan
de la forma:
Cadena=concat (val1, val2, ..); por ejemplo:
Concat(`El, ` `, `XML) devuelve: `El XML
Contains() Devuelve true o false dependiendo de que la segunda cadena presente
en sus argumentos est contenida en la primera, de la forma: boolCcontains Oval%
surcad@; por ejemplo:
Contains(`XML, `X) devuelve: true
108
4tartsRPith() Devuelve true o false dependiendo de que la primera cadena empiece
o no con la segunda, de la forma: boolCstartsRPithOcadena% surcad@I por
ejemplo:
Starts-with(`XML, `X) devuelve: true.
4trin'() Convierte el valor del argumento en una cadena de la forma:
Cadena= string(valor); p.e.:
String(314) devuelve: `314
4ubstrin'() Devuelve la parte de la cadena que se especifica en los argumentos de
la forma:
Substring(`beatles, 1, 4) devuelve: `Beat
Translate() Efecta un reemplazo carcter a carcter del primer argumento (valor)
de forma que tras examinar el valor del argumento del segundo argumento
(cad1)reemplaza cada carcter por el carcter que aparece en la misma posicin de
(cad,) de la forma:
Cadena=translate(valor, cad1, cad2). Son ejemplos:
Translate(`12:30, `30, `45) da como resultado: `12:45
Translate(`12:30, `30, `54) da como resultado: `12:45
Translate(`12:30, `0123, `abcd) da como resultado: `bc:da

4obre nVmeros
Ceilin'(). Devuelve la mejor cota entera superior del nmero que aparece en el
argumento de la forma: numero=ceiling(numero); por ejemplo:
Ceiling(3.14) devuelve: 4.
Aloor(). Devuelve la mayor cota entera inferior del nmero que aparece en el
argumento de la forma: numero=floor(numero); por ejemplo:
Floor(3.14) devuelve: 3.
1umber(). Convierte el valor que aparece en su argumento en un nmero de la
forma: numero=number(valor); por ejemplo:
109
Number(`100) es 100.
0ound(). Redondea el nmero del argumento al entero ms prximo de la forma:
entero=round(numero); por ejemplo:
Round(3.14) devuelve: 3.
:oolenas
:olean(). Convierte el valor de los argumentos a verdadero o falso de la forma:
Bool=bolean(valor)
Lan'(). Devuelvan cierto si el lenguaje concuerda con el lenguaje que corresponde
al elemento !sl.lan', y en caso contrario devuelve falso, de la forma:
Bool=lang(lenguage).
1ot(), Devuelve cierto si el elemento condicin es falso y falso si el argumento
condicin es verdadero, de la forma:
Bool=not(condicion)
Con lo visto se comprueba que XPath se centra en declarar la parte de documento
que se desea seleccionar, de forma que evita tener que crear un cdigo que escaln
a escaln localice y obtenga el nodo deseado. Su forma de trabajar es parecida
tanto a la de un Sistema Operativo como la usada dentro de los URIs, siendo sta
una de las razones que explican que XPath no est escrito en XML, ya que con ello
una expresin XPath puede usarse como atributo de un elemento XML, puesto que si
estuviera escrita con sintaxis XML sera necesario utilizar de forma muy reiterada
caracteres de escape con la falta de claridad que ello supondra.

NOTA: XPath es una herramienta que, adems de formar parte de la familia XML,
tambin se usa en otros entornos de programacin, no siempre tan estandarizados.
A modo de simple ejemplo, sealemos que la funcin select1odes de Internet
Explorer toma la forma: xmlobject.selectNotes(expresin XPath). Son ejemplos de
su uso:

- !ml$oc#select1odes ("/comidas/plato). Para seleccionar los platos de las
distintas comidas.
110
- !ml$oc#select1odes ("/comidas/plato[0]) que selecciona el primer nodo
(aunque esto es especifico de IE 5, que usa [0] como primer nodo, cuando en
el estndar W3C es [1]).
- !ml$oc#select1odes ("/comidas/plato/precio) que selecciona todos los
precios.
8#8# 1ombres escuetos
En el proceso de localizacin dentro de u documento se han desarrollado distintas
expresiones, todas ellas basadas en XPath, cuyo objetivo es mejorar y aprovechar
las posibilidades que ofrece este lenguaje. A modo de ejemplo del tipo de problemas
que pueden aparecer vamos a plantear una situacin, felizmente resuelta, que indica
el grado de flexibilidad que se necesita a la hora de localizar determinadas partes de
un documento XML, que puede estar sometido a cambios ms o menos constantes y
que en consecuencia van a acabar por afectar a este proceso de localizacin.
Como hemos visto, XPath utiliza secuencias de hijos que se direccionan mediante
el uso de la posicin relativa de los nodos dentro de la presentacin en rbol del
documento fuente. Esta aproximacin no presenta problema alguno si la estructura
del documento XML sobre el que se acta es conocida, sin embargo, si esta
estructura no se controla, el uso de la posicin relativa para la localizacin puede
suponer una limitacin importante, que hay que superar.
Consideremos el ejemplo de un documento tecnolo')as#!ml que lista algunas
tecnologas XML:
<?xml version=`1.0?>
<Tecnologas.XML id="ElementoDoc>
<TecnologiaXML> XML </TecnologiaXML>
<TecnologiaXML> XML Schema </TecnologiaXML>
<TecnologiaXML> XSLT </TecnologiaXML>
</TecnologiaXML>
Si se quiere localizar el elementos hijo de TecnologiaXML que contiene el texto
"XSLT con XPath, se usa la secuencia: /1/3, o tambin al haber incorporado el
atributo id se puede usar una sintaxis alternativa escribiendo: +lemento$oc se
refiere al valor del atributo id del elemento tecnolo')as#!ml y 3 al tercer nodo hijo
relativo a este contexto.
Supngase que se actualiza el archivo, con desconocimiento de la aplicacin que lo
usa, de forma que el documento pasa a ser:
111
<?xml version=`1.0?>
<TecnologiaXML id="ElementoDoc>
<TecnologiaXML> XML </TecnologiaXML>
<TecnologiaXML> XML Schema </TecnologiaXML>
<TecnologiaXML> XML Schema </TecnologiaXML>
<TecnologiaXML> XPath </TecnologiaXML>
<TecnologiaXML> XSLT </TecnologiaXML>
</TecnologiaXML>
Con estos pequeos cambios en el documento, ni la expresin /1/3, ni
ElementoDoc/3 localizarn el nodo elemento deseado ya que ambas secuencias
estn estrechamente acopladas a la anterior estructura del documento
Tecnolo')as#!ml y en consecuencia la aplicacin dejar de funcionar
correctamente.
Al objetivo de superar circunstancias como sta, y en consecuencia para poder
trabajar con independencia de los cambios efectuados en un documento, se
incorpora una sintaxis llamada nombres escuetos (*are names), que no son otra
cosa que el uso de nom*re como argumentote las posibilidades que ofrece el uso del
atributo id dentro de la estructura del documento.
La idea que hay detrs del uso de los nombres escuetos es proporcional una
sintaxis que use para la localizacin de los elementos correspondientes el valor de
los atributos id, de tal manera que al examinar las secuencias hijo, los elementos
con atributo id pueden direccionarse sin que les afecte cualquier cambio en la
estructura del documento, puesto que siempre que el elemento mantenga un
atributo id nos podremos dirigir a l utilizando esta sintaxis.
Veamos su funcionalidad en el problema de los posibles cambios efectuados en el
documento fuente. Supongamos que la informacin del anterior documento la
escribimos incorporando a los distintos elementos los respectivos atributos id cuyo
nuevo archivo llamaremos Tecnolo'ias*$1#!ml.

<?xml version=`1.0?>
<TecnologasXML id="ElementoDoc>
<TecnologiaXML id="XML> XML </TecnologiaXML>
<TecnologiaXML id="XMLSchema> XML Schema </TecnologiaXML>
<TecnologiaXML id="XSLT> XSLT </TecnologiaXML>
</TecnologasXML>
Usando la sintaxis de nombres escuetos se puede acceder directamente al nodo
elemento hijo Tecnolo'iaXML, que antes localizbamos con una secuencia,
mediante la sintaxis: Tecnolo'ias*$1#!ml>X4LT. Al modificar el documento
112
Tecnolo'ia*$1#!ml en el sentido anterior, manteniendo el uso del atributo id, que
para distinguirlo lo designaremos por Tecnolo'ias*$,#!ml, tendremos:
D?xml version=`1.0?>
<TecnologasXML id="ElementoDocE
<TecnologiaXML id="XML> XML </TecnologiaXML>
<TecnologiaXML id="XMLSchema> XML Schema </TecnologiaXML>
<TecnologiaXML id="Xpath"> Xpath </TecnologiaXML>
<TecnologiaXML id="Xpointer> Xpointer </TecnologiaXML>
<TecnologiaXML id="XSLT> XSLT </TecnologiaXML>
</TecnologasXML>
Podemos usar perfectamente la sintaxis: Tecnolo'ias*$,#!ml>X4LT para localizar
el elemento deseado.
Con se observa con el uso de esta sintaxis se puede manejar el elemento que
interesa, siempre que este presente en el documento. Por tanto, gracias a las
posibilidades del atributo id se tiene un procedimiento para el direccionamiento de
documentos XML, cuya estructura actual puede ser desconocida por la aplicacin y
que sustituye el uso de la secuencia de hijos. Como puede verse en esta seccin se
ha dado un ejemplo de localizacin que generaliza algunas de las posibilidades de
XPath.
8#K# +!tender XPath. concetos de Xointer
En la lnea de los visto de la seccin anterior, con los nombres escuetos aparece la
idea consistente en que dada una URIref como: "http://www.sitio.com/dos.xml, se
le puede aadir a la misma un identificador de fragmento que ser de la forma:
#xpointer (XXX), donde XXX sea una o varias expresiones XPath que al evaluarse
devuelvan un conjunto de nodos en condiciones de ser utilizados para lo que se
necesite. As, en la direccin que hemos dado, si se tuviera al final de la misma:
..doc.xml#xpointer(/libro/capitulo[.@public])xpointer(/libro/capitulo[@num="2])
Se esta ra en condiciones de buscar en .doc#!ml el conjunto de nodos
delimitado por 6libro6caitulo, y en el caso de que no existiese ninguno, se
pasara a 6libro6caitulo]\numS,S^.
Xointer es una Recomendacin W3C basada en XPath, que permite cosas tales
como que al cargar un visualizador se seleccionen slo los elementos que interesan,
o que la parte seleccionada no se muestre el usuario y simplemente se aada a un
conjunto de datos. Para que esta versatilidad sea til, es importante retener que lo
113
que vaya a hacerse con el fragmento identificado debe depender totalmente de la
aplicacin que lo que XPointer se limita a hacer de puente entre sta y los distintos
tipos de recursos para la localizacin.
Las funcionalidades de Xpointer son similares a las que un procesador de textos
presenta respecto a algunas partes de un documento, como cuando al sealar un
punto o segmento particular del mismo, el procesador lo abre por el lugar ms
adecuado proporcionando el contenido correspondiente debidamente destacado.
XPointer se diseo para identificar fragmentos de cualquier tipo de recurso
(text/xml, text/xml-external-parsed-entity, etc.) proporcionando mecanismos para
"apuntar a estos distintos tipos, con el objeto de permitir el enlace con estos
segmentos de inters, con la generalidad aadida que supone que XPointer pueda
hacerlo, tanto si forman parte de un documento XML, como si lo son de una entidad
externa analizable.
Siguiendo a XPath, Xpointer trabaja utilizando: ejes, comprobacin de
localizaciones (anlogamente a los nodos de comprobacin), predicados y funciones
(aplicando las existentes en XPath). Xpointer adems existente la notacin de rbol
XPath a las entidades analizables externas, incluso aunque stas no sean un
documento XML bien formado.
8#K#1# Puntos & ran'os
Obsrvese que aunque en XPath se puede seleccionar un nodo tal como
<autor>Pepa BentezD6autorE, no se puede llegar hasta detallar la primera
palabra de su contenido ("Pepa). Al objeto de superar esta limitacin y conseguir
ms seguridad, Xpointer considera que tanto entre dos caracteres consecutivos de
un texto, como entre cada par de elementos consecutivos, existe lo que se llama un
unto, que se define como toda posicin inmediatamente anterior o posterior a un
carcter o a un modo. As, en el fragmento:
<documento>
<saludo> Hola! </saludo>
</documento>
Existen 14 puntos:
1& Antes del nodo raz,
2& Antes del nodo saludo,
3& Antes del nodo texto Hola!
4& Antes del espacio en blanco que hay antes de Hola!
5& Antes del carcter ,
114
6& Antes de la letra H,
7& Antes de la letra O,
8& Antes de la letra l,
9& Antes de la letra a,
10& Antes del carcter ,
11& Despus del texto que finaliza con !,
12& Despus del espacio en blanco que separa ! y /saludo,
13& Despus de /saludo,
14& Despus del nodo raz.
Se llama ran'o al fragmento de texto comprendido entre dos puntos, esto es, el
rango describe cualquier zona continua de un documento, comenzando en un
determinado punto y finalizando en otro, determinados ambos por una expresin
XPath. Como ejemplo de rango, se puede citar el proceso de seleccionar con el ratn
un trozo de documento, que puede perfectamente ir a la mitad de un prrafo hasta
tres captulos ms abajo del documento.
En XPointer se generaliza la idea de nodo XPath, con la definicin de location,
que puede ser bien un nodo (como en XPath), o uno de los conceptos que se acaban
de introducir: punto o rango. Con ello aparece un tercer concepto, el de
locali7acin, formada por el conjunto de nodos al que se le aaden sus rasgos y
puntos correspondientes, designndose locationRset a la lista de localizaciones
producida por una expresin XPointer. Se usa la nocin de coverin' ran'e para
referirse al rango que contiene completamente una location.
8#K#,# Locali7aciones
$e untos: un punto se especifica con un conector de nodos (container node)y un
ndice (inde!) no negativos entre corchetes. Para definrsete ndice se distinguen
dos posibilidades segn que el container node sea:
a) Un nodo raz o un nodo elemento (en cuyo caso el ndice representa los nodos
hoja incluidos en l) recibiendo el nombre de untoRnodo Onode oint@.
b) Un tipo perteneciente a los nodos del rbol XPath que no pueden tener nodos
hijos, recibiendo el nombre de untoRcar=cter OcharacterRoint@ en cuyo
caso, el ndice debe ser estrictamente positivo y no mayor que la longitud de la
cadena del valor del texto correspondiente al nodo.
Para manejar los puntos en una expresin XPointer se recurre a la funcin ointO@ a
la que hay que aadirle un predicado, en forma de expresin XPath, indicando el
115
punto concreto que se desea. Por ejemplo, para seleccionar el cuarto hijo del nodo
raz, se escribe:
/point()[position()=4]
Y para seleccionar la dcima letra de un nodo texto, de un elemento libro se
escribe:
/libro/text()/point()[position()=10].
Como se observa, en una localizacin, los puntos carecen de dimensin, ya que
toman el valor de una cadena vaca. As, para el manejo de los ejes XPath dentro del
contexto XPointer conviene tener en cuenta posibles situaciones especiales, tales
como que el eje sel( de un punto contenga el propio punto, que el eje arent
contenga al propio punto, que el eje arent contenga el nodo contenedor del punto,
etc.
$e ran'os: para especificar un rango se adopta el crdito que si el punto inicial
(o final) es un conjunto de nodos, se considera el primero (o ltimo) de ellos como
se pudo nodo soda (o final). A la hora de localizar rangos, hay que reparar que se
pueden dar dos posibilidades: que haya ms de un nodo involucrado en l o que el
rango buscado est dentro de un solo nodo. Para ver el primer caso, considrese el
ejemplo:
<Factura>
<Nombre>Juan Luna</Nombre>
<Direccin1>Cualquier Calle1</<Direccin1>
<Direccin2>Alguna localidad </Direccin2>
<Cuidad>Cualquier Cuidad</Cuidad>
<CodigoPostal>12345</CodigoPostal>
<Pais>Chile</Pais>
</Factura>
Y supngase que se quiere seleccionar el segmento que va desde inmediatamente
antes del nodo nombre hasta despus del nodo ciudad. Para ello se aplica la
sentencia:
XPointer(/Factura/Nombre to /Factura/Cuidad)
Donde aparecen dos trayectos de bsqueda separados por to. El primer trayecto
selecciona el nodo elemento 1ombre, y en este contexto indica que el comienzo del
rango est inmediatamente antes del elemento nodo 1ombre, el segundo
selecciona el nodo elemento Cuidad; de forma que la palabra clave to indica que el
116
rango acaba inmediatamente despus del nodo especificado en este segundo
trayecto de localizacin.
Veamos cmo obtener el rango dentro de un mismo nodo. Supongamos que
tenemos un solo nodos texto en l un determinado rango, algo por cierto, que
sabemos no poder hacerse en XPath. Sin embargo, gracias a XPointer, se puede
seleccionar un rango dentro del mismo nodo para lo que se debe especificar dos
lmites: el punto de partida de la cadena elegida y el punto final de esta cadena.
Supongamos que se quiere seleccionar las primeras dos palabras: "Una causa,
supuestamente situadas en la primera frase del segundo prrafo, de un texto. As, el
punto inicial est inmediatamente antes de "U y tiene un ndice (), con lo que el
punto de partida es:
XPointer(/Capitulo/Parrafo[2]/text()[0]).
De forma similar al estar el punto final inmediatamente despus del carcter QaS
de QcausaS su ndice es 8. En base a ello, se puede localizar el punto final como un
untoRcar=cter que vendr por la expresin:
XPointer(/Capitulo/ parrafo[2]/text()[8])
Por lo tanto el rango deseado, dentro del mismo nodo, puede escribirse como:
XPointer(/Capitulo/parrafo[2]/text()[0] to / Capitulo/parrafo[2]/text()[8])
8#K#2# +s-uemas en XPointer
XPointer incorpora tres esquemas: !ointer% !mlns% y element. Como se ha
adelantado, !ointer se utiliza para seleccionar puntos (punto-nodo o punto-
carcter) y puede usarse siempre que no interfiera con el Espacio de Nombres. As
se escribe:
!ointer(algunalocalizacin) o !ointer(algunalocalizacin to otralocalizacin).
La existencia en XPointer de un esquema xmlns, que en XML se refiere al espacio
de nombres, es perfectamente coherente y necesaria, ya que en ocasiones
expresiones como:
miDocumento.xml#xpointer(//mi:elemento)
que aparentemente no presenta ninguna duda, devuelven el locationRset (que en
este caso consistira en todos los descendientes del nodo mi.elemento del
117
documento, mi$ocumento#!ml) pueden ser objetote incertidumbres, tales como
conocer la forma de aplicarse a documentos tales como:
<mi:Documento xmlns:mi="http://editar.com>
<mi:elemento>Algn contenido>/mi:elemento>
<mi:elemento xmlns:mi="http://www.svgspider.com>
Otro contenido
</mi:elemento>
</mi:Documento>
Sin entrar en detalles, conviene saber que estas ambigedades son evitables con
el uso del esquema !ointer#!mlns.
El tercer esquema, elementO@ tiene como objetivo dirigir directamente a un
elemento, pudindolo hacer bien mediante su nombre (por ejemplo: element
Ointro@), o bien identificndolo en una secuencia de hijos, asumiendo que el recurso
es el propio documento; por ejemplo: elementO616,@ identifcale segundo
elemento hijo dentro del elemento raz. Ambas aproximaciones se pueden combinar,
navegando a partir de un elemento localizado por su nombre. As,
elementOintro6261@ apunta al elemento resultante de localizar el elemento
identificado por el valor "intro, despus localizar su tercer elemento hijo y
finalmente identificar el primer elemento hijo de ste.
8#K#5# +!resin a XPointer de las (unciones de XPath
Todas las funciones XPath son accesibles para los procesadores XPointer, que
presenta adems funciones adicionales, de las que vamos a ver, a modo de ejemplo,
las ms representativas agrupndolas por el concepto XPointer con el que se
relaciona.
Aunciones relacionadas con LocationR4et
- ran'eRto() a partir del nico argumento location-set devuelve un rango para
cada miembro del mismo. As, dado el fragmento:
<parrafo id="para1 numero="1>
<!-Algn contenido va aqu ->
</parrafo>
</parrafo id="para2 numero="2>
<!-Otro contenido va aqu ->
</parrafo>
118
Para dirigirse a l, se escribe:
xpointer(id("para1)/range-to(id(para2)))
donde ran'eRto() se usa para expresar el rango con el elemento Parra(o cuyo
atributo id tiene el valor de ara1 acompaado de su punto de partida y se utiliza
para identificar un segundo punto como punto final, el cual tambin es un nodo
elemento Parrafo que tiene un atributo id con el valor de ara,. Observaremos que
ran'eRto a partir de location-set devuelve un conjunto de rangos sin dar el
contenido de los mismos. Si estos contenidos interesaran, existen funciones que
devuelven un conjunto de localizaciones, a partir del contenido de cada una de ellas,
que se pasan como parmetro.
- strin'Rran'e() proporciona una cierta capacidad para la seleccin de
cadenas. Esta funcin necesita dos parmetros, el primero es un conjunto de
nodos donde buscar y el segundo la cadena buscada. Devuelve un conjunto de
nodos que contienen un rango por cada aparicin de la cadena buscada. L a
funcin admite otros dos parmetros opcionales, )ndice y lon'itud, para
indicar, una vez hecho el emparejamiento objeto de esta funcin, cuntos
caracteres se deben dejar pasar al empezar el rango y cuantos caracteres ms
debe tener ste. La sintaxis es:
string-range (node-set, substring, index, length).
son ejemplos:
xpointer(string-range(/, "noche)) busca todas las apariciones de noche en el
documento.
xpointer( string-range(//capitulo/titulo, "calle))busca dos apariciones de calles en
los ttulos del documento.
El tercer argumento, opcional consiste en un nmero que define la posicin del
primer carcter que debe incluirse en el rango a obtener, siendo 1 el valor por
defecto; por ejemplo: strin'Rran'eO66Parra(o% QsobrentendidoS% 5@ dar como
resultado rangos que contengan la parte "entendido de "sobrentendido ya que le
indicamos que la funcin deje pasar 4 caracteres. El cuarto argumento, tambin
opcional, es un nmero que define el cardinal de caracteres del rango que se
devuelve; por ejemplo: strin'Rran'eO66Parra(o% QmalentendidoS% 2% 8@ da como
resultado rangos que contengan la parte "enten. El valor por defecto es la longitud
del segundo argumento.
Aunciones -ue devuelven las locali7aciones -ue delimitan otra locali7acin
119
- 4tartRoint() tiene como nico argumento locationRset y devuelve a su vez
un location-set de puntos de partida, esto es, devuelve un conjunto de
localizaciones que aaden al argumento que corresponde al primer punto de
cada una de las localizaciones del argumento; por ejemplo: startR
ointO66caitulo]1^@ devuelve un solo punto que es justo el anterior al
primer elemento de tipo capitulo.
- endRoint() similar a la funcin anterior, referida al locationRset de puntos
finales. El punto devuelto representa el punto final del argumento location#R
set# As por ejemplo endRointOlocationRset@ devuelve justo un conjunto de
localizaciones en el argumento location#set, la funcin endRointO@ aade un
punto al locationRset devuelto.
Aunciones de conte!to
XPointer aade a la ya conocida funcin idO@las funciones hereO@ y ori'inO@ que
pueden ser consideradas como dos funciones encargadas de dar informacin al
contexto de la localizacin dentro de XPointer.
- here() no tiene argumentos y devuelve un locationRset. Debido a que no
puede estar en dos sitios al mismo tiempo, el location-set devuelto contiene
un solo miembro. Esta funcin se utiliza en expresiones que apuntan a zonas
internas del propio documento (como veremos, normalmente este "apuntar
correspondiente a Xlink) haciendo referencia al nodo contexto desde el cual se
hace la llamada mediante su URI.
- ori'in() se utiliza tambin en expresiones XPointer relacionadas con enlaces
de Xlink, y se refiere al momento desde el cual se produjo el salto. Esta
funcin tampoco tiene argumentos y devuelve un locationRset. Para obtener
su sentido, la funcin origin() se procesa en reunin a un XPointer como parte
de un enlace de un documento XML ya que si se indica a algo que no sea XML,
lo que se devuelva como tal location-set carecer de sentido.
Como tendremos ocasiones de ver, el usote XPath dentro de la familia XML es muy
extenso, y de hecho el modelo de los datos actualmente propuesto para XPath se ha
elaborado conjuntamente con el de XQuery. Como veremos en su momento, las
relaciones entre XPath y XQuery son intensas ya que ambos usan expresiones
regulares para navegar en la estructura lgica de un documento. La especificacin
XQuery copia de la especificacin XPath como parte de ella, y de hecho, no slo
permite el simple uso de expresiones XQuery como operandos de construcciones
120
XPath, lo que incluso cambia la perspectiva y el alcance del lenguaje XPath. De
hecho XQuery se considera una ampliacin de XPath al soportar, en base a l,
consultas a ms de un documento.
Aunque las nuevas recomendaciones son muy prolijas, superando con mucho la
ptica de este texto, debe retenerse que lo visto en este captulo constituye la base
para la localizacin y navegacin de las distintas partes del documento XML, cosa
que constituye un prerrequisito para cualquier explotacin de la informacin
contenida en el mismo.
K CAP*TULO
Tecnolo')as ara enla7ar documentos XML

6.1. XML Base
6.2. XML Inclusin
6.3. XLink: Instruccin y Conceptos bsicos
6.4. Elementos en XLink
6.5. Atributos en XLink
6.6. Las posibilidades de XLink
Aunque la sintaxis bsica de XML proporciona una estructura que da contenido a los
documentos, se habr observado que esta sintaxis por s sola no es capaz de
describir completamente ni las relaciones entre recursos (o sus identificadores)
dentro de un mismo documento, ni las mutuamente existentes entre documentos
diferentes (o fragmentos de ellos). Al objeto de superar estas limitaciones, existen
tres tecnologas estandarizadas y complementarias entre s, que siguiendo la
filosofa y principios del XML abordan las relaciones externas que se pueden dar en
el seno de un documento.
;M2 Include es una Recomendacin que tiene como objetivo resolver el tema de
la inclusin de varios documentos es uno mayor, ;M2 Case proporciona un
mecanismo para flexibilizar el uso de las URI que se deben utilizar en cada
momento, y ;lin5 aborda el tema de los enlaces entre documentos. Las tres
recomendaciones en su conjunto resuelven razonablemente bien tanto la inclusin
de uno documentos en otros documentos XML, como los problemas derivados de los
hiperenlaces entre distintos documentos.
121
K#1# XML :ase
Recurdese que el HTML, el uso del elemento <base href="." permite especificar
un URI (normalmente en forma de URL) respecto a la cual se referencia el
documento; con ello se facilita que determinados atributos tales como href, src y
longdesc reconozcan este identificador como la URIref a utilizar, y es precisamente
usando esta posibilidad como trabajan muchos buscadores que estn programados
para explotarla para hacer su trabajo. Ntese que a pesar de su importancia, en
HTML este URI "base slo se aplica a los valores de unos atributos previamente
determinados, y no es posible hacerlo con otros que puedan aparecer en el
documento (por ejemplo, height, alt, o border).
XML, al contrario que HTML, en principio no asigna la posibilidad de proporcionar
una URIref a ningn atributo en particular, sino que permite que esta referencia
pueda declararse en cada caso concreto donde sea necesario contar con esta
posibilidad. Ntese que en la prctica esta facilidad acaba significando cul debe ser
la aplicacin encargada de especificar la base sobre la cual resolver las URIref que
aparezcan en el proceso.
Para conseguir esta flexibilidad existe una Recomendacin W3C que proporciona
un mecanismo para declara un URI "base en cada momento, de forma que a partir
de ella se van a resolver las URIref relativas que puedan ir apareciendo. Ello permite
que estos URIs no tengas por qu ser nicos para la totalidad de documento, sino
que puedan asociarse a porciones ms pequeas del mismo, haciendo factible que
cualquier elemento pueda tener su propio atributo para especificarlas, lo que
proporciona una gran portabilidad a los documentos, que puedan reutilizarse con
mucha mayor flexibilidad.
Como se tendr ocasin de constatar, estas nuevas posibilidades tienen
implicaciones para otras tecnologas XML, y ms concretamente a la hora de
seleccionar los enlaces (en especial con XLink que veremos en este captulo) de
forma que con este mecanismo cada elemento puede resolver sus respectivas URI
relativas a travs de los valores que toman sus atributos. El caso ms significativo
es el atributo xlink:href que como veremos una funcionalidad parecida a su
homlogo de HTML con la citada diferencia de que, en el marco de XML, se puede
utilizar uno de estos atributos para cada elemento que lo necesite y as tener ms
capacidad para cubrir los objetivos de cada uno de ellos.
Vamos a mostrar la forma de trabajar del atributo reservado xml:base, utilizable
con cualquier elemento XML, y que acepta como valor cualquier URIref vlida, tanto
absoluta como relativa. Consideremos un fragmento de la forma:
122
<elemento1 xml:base="http://www.khyri.com>
.
<contenido xml:base="/kim/>
.
</contenido>
</elemento1>
y observemos que sea quien sea el posible URI del documento al que pertenece este
fragmento, el elemento1 y sus hijos, salvo indicacin expresa, tiene como URI a:
http://www.khyri.com/. Adems al usar xml:base="/kim/ en el elemento hijo
contenido, para l y sus posibles elementos hijos, el URI a manejar es:
http://www.khyri.com/kim/.
Como se observa xml:base proporciona un URI base a elemento1 con
independencia de lo que pueda aparecer en el resto del documento y ello no impide
utilizar nuevos atributos !ml.base sobre otros elementos e interpretarlos en
relacin con los URIs base de sus nodos padre si los tuvieran, como ocurre con
contenido respecto a elemento1.
El ejemplo siguiente muestra una aplicacin de esta facilidad en un documento
que describe una coleccin de pginas Web, cuyos enlaces funcionalmente son
similares a la construccin hre(CQ[Sen "TML y que sirve para encuadrar el papel
de !ml.base a la hora de enlazar documentos XML(ya hemos adelantado que el uso
del atributo !lin9.hre( es anlogo al de su homlogo XML). Supongamos que
pretendemos tener actualizada una lista de xitos discogrficos en una emisora de
radio y observemos el contexto de valores que va tomando el atributo !ml.base.
<?xml version="1.0?>
<doc xml:base="http://ejemplo.org/hoy/
xmlns:XLink="http://www.w3.org/1999/xlink>
<parrafo>ver <link xlink:type="simple xlink:href="nuevo.xml>las
novedades</link></parrafo>
<olist xml:base="/massolicitado/>
<item>
<link xlink:type="simple xlink:href="massolicitado1.xml numeros
1</link>
</item>
<item>
<link xlink:type="simple xlink:href="massolicitado2.xml>Nmero.
2</link>
</item>
</olist>
</doc>
123
donde las URIs presentes en este ejemplo se resolvern de la siguiente forma:
"Ver las novedades a "http://ejemplo.org/hoy/nuevo.xml"
"Nmero 1 a "http://ejemplo.org/massolicitado/massolicitado1.xml
"Nmero 2 a http://ejemplo.org/massolicitado/massolicitadi2.xml
con las posibilidades de adaptacin y actualizacin que ello supone para poder tener
actualizada la informacin acerca de cada momento.
Por tanto !ml.base generaliza la funcionalidad BASE de HTML a documentos XML,
una posibilidad que aprovecharemos en el resto del capitulo, tanto para insertar
elementos en documentos XML, como para crear y describir hiperenlaces entre
recursos, que sern ms sofisticados que los urbanos en HTML.
K#,# XML *nclusin
La capacidad para incorporar fuentes externas de informacin parecida a la inclusin
de bibliotecas de programas en los lenguajes de programacin afortunadamente
tambin se da en el seno de XML, solo que ahora obviamente con documentos. Para
hacerlo posible la familia XML proporciona un mtodo que permite insertar en un
documento el contenido, parcial (especificado mediante XPointer) o total, de otro
documento XML.
Por razones relacionadas con la seguridad en la Web (estamos hablando de incluir
documentos de distintas procedencias) la Recomendacin XInclude ha sido objetivo
de un amplio debate, que por fin, en el momento de terminar el presente libro, es ya
una Recomendacin W3C final.
Para ubicar esta tarea, consistente en incorporar distintos documentos en uno
mayor, recordemos que las entidades externas, tanto en forma de una DTD como en
un Esquema, se pueden incluir en un documento procedente de una fuente eterna al
mismo. Sin embargo, el objetivo que aborta la tecnologa XInclude no es ste, sino
que en cierta manera es complementario, ya que su objetivo consiste en que un
documento XML muy extenso se pueda formar usando mltiples documentos, sean o
no de texto XML. Ntese que la referencia a una entidad externa se procesa durante
el anlisis del documento, mientras que por su naturaleza XInclude describe un
proceso que inevitablemente debe hacerse con prioridad al anlisis del documento,
cuando los datos correspondientes ya estn almacenados. De hecho, XInclude al
trabajador a alto nivel, permite preservar informacin clave como son las URIs base
y los espacios de nombres apropiados que se insertan en el momento adecuado.
124
La especificacin XInclude tiene como espacio de nombres el URI:
http://www.w3.org/2001/xinclude (para el que suele usarse el prefijo !i)
reducindose su contenido al uso de dos elementos (!i.include y !i.(allbac9).
K#,#1# +l elemento !i.include
Este elemento presenta la siguiente sintaxis y atributos:
<xi:include
xmlns:xi="http:///www.w3.org/2001/xinclude"
href="URI
parse="xml/text
encoding="tipo de cdigo/>
donde el contenido a ser incluido en el documento viene dado por el atributo hre(,
que tiene como valor un URI, que puede venir dado de forma explcita o por medio
de una expresin XPointer, con lo que se cubre tambin la posibilidad puede incluir
cualquier tipo de contenido, tales como textos o elementos que provocan de un
documento externo. Este atributo es obligatorio en la declaracin, pues sin una
referencia al recurso a incluir el propio elemento careca de sentido.
En el proceso de inclusin es posible el anidamiento, aunque en el mismo no estn
permitidos ni los bucles de inclusin ni la autoinclusin del documento.
El atributo arce es opcional y puede tomar dos valores: "xml (que es el valor
por defecto). o "text, de forma que "xml significa que el recurso externo invocado
se analiza como un documento XML, pudindole aadir si fuera necesario los
atributos reservados que fueran de menester. Por su parte, "text indica que el
recurso externo se convertir en un nodo texto, que entre otras cosas supone que
los parntesis <> se convierten en las entidades &lt; &gt;. Ntese que si un
fragmento se analiza como "text en las posteriores inclusiones que se puedan dar,
ya estar convencido en el texto normal dentro de un documento, y por tanto no
hay que preocuparse respecto a los posibles bucles de inclusin que se puede dar.
El tercer atributo, tambin opcional, encodin' permite dar la codificacin de
caracteres del texto que van a ser incluidos, y obviamente slo tiene sentido su uso
si el atributo arse toma el valor "text, ignorndose en el caso que fuera "xml.
Una vez vista la sintaxis de la inclusin, veamos los tipos de inclusiones que se
producen, y que puedan obedecer a distintos patrones. Para la presentacin de los
distintos casos, se asume en todos ellos que se trabaja respecto a una misma URI
base, concretamente: http://www.ejemplo.org/documento.xml.
125
*nclusin de un documento
Dado el documento:
<?xml version=`1.0?>
<documento xmlns:xi="www.w3.org/2001/XInclude>
<p>men de platos en diferentes idiomas </p>
<xi:include href="menuespanol.xml/>
</documento>
donde el documento "menuespanol.xml a incluir es:
<?xml version=`1.0?>
<descripcin>
<p>paella de mariscos, arroz al horno, bandeja fruta</p>
</descripcin>
Al resolver la inclusin, el resultado coincide con el documento:
<?xml version=`1.0?>
<documento xmlns:xi="http://www.w3.org/2001/XInclude>
<p> men de platos de diferentes idiomas.</p>
<descripcin xml:base="http://www.example.org/menuespanol.xml>
<p>paella de mariscos, arroz al horno, bandeja fruta </p>
</descripcin>
</documento>
*nclusin de un te!to en un documento
Dado el documento:
<?xml version=`1.0?>
<documento xmlns:xi="http://www.w3.org/2001/XInclude>
<p> El precio del plato es
<xi:include href="precio.tnt parse="text/> pesos.</p>
</documento>
Donde se supone que recio#t!t contiene: 10000. Al resolver la inclusin, el
resultado coincide con el documento:
<?xml version=`1.0?>
126
<documento xmlns:xi="http://www.w3.org/2001/XInclude>
<p> El precio del plato es 10000 pesos.</p>
</documento>
*nclusin de un ran'o eseci(icado mediante XPointer
Dado el documento:
<?xml version=`1.0?>
<documento>
<p>El extracto relevante es:</p>
<comillas>
<include xmlns="http://www.w3.org/2001/XInclude
href="fuente.xml xpointer ="xpointer (string-range(capitulo/p[1], `frase 2)/
range-to (/capitulo/p[2]/I, `3., 1, 2)))/>
</comillas>
</documento>
Donde (uente#!ml contiene:
<capitulo>
<p>Frase 1. Frase 2.</p>
<p><i>Frase 3. frase 4.</i> frase 5.</p>
</capitulo>
Al resolver la inclusin el resultado coincide con el documento:
<?xml version=`1.0?>
<documento>
<p> El extracto relevante es:</p>
<comillas>
<p xml:base="http://www.ejemplo.com/fuente.xml>Frase 2.</p>
<p xml:base="http://www.ejemplo.com/fuente.xml><i>Frase 3.</i></p>
</comillas>
</documento>
NOTA: Obsrvese que los ejemplos anteriores, en el resultado de la inclusin aparece
el atributo !ml.base. El objetivo de ello es prever la posibilidad de las referencias de
la URI relativas que pudieran aparecer en el documento resultante puedan dejar de
jugar su papel cuando se vayan a incluir en otro documento o en otro fragmento del
mismo documento.
127
K#,#,# +lemento !i.(allbac9
Este segundo elemento de XInclude proporciona un mecanismo para recuperar
recursos perdidos, de forma que cuando por la razn que fuera, un recurso que se
quiera incluir no est accesible (problemas de conexin, restricciones de seguridad,
recursos no existentes, esquema de la URI desconocido o no localizable, etc.)
entonces se incluya en su lugar el contenido del elemento !i.(allbac9. As, en el
ejemplo:
<pagina xmlns:xi="http://www.w3.org/2001/XInclude>
<cabecera>universidad de valdivia </cabecera>
<xi:include href="http://www.uv.es ">
<xi:fallback>Lo sentimos, el sitio Web de la universidad de valdivia no se
encuentra disponible en este momento <xi:fallback>
</xi:include>
</pagina>
si el recurso http://www.uv.es no estuviera accesible en un momento determinado,
aparecera el mensaje que acompaa a !i.(allbac9.
El elemento !i.(allbac9 no tiene atributos, y es hijo directo del elemento
!i.(allbac9 de forma que su contenido no tiene ninguna restriccin, con lo que
puede contener incluso cualquier instruccin que proporcione una forma alternativa
de recuperar el recurso a incluir.
Con este nuevo elemento de XPointer se puede completar la serie de los cuatro
ejemplos vistos de la seleccin anterior, con un quinto, en el que se trata un caso en
el que no se dispone del documento a incluir:
<?xml version=`1.0?>
<div>
<xi:include href="ejemplo.txt parse="text
xmlns:xi="http://www.w3.org/2001/XInclude>
<xi:fallback>
<xi:include href="ejemplo.olvidado.txt parse="text>
<xi:fallback><a href="mailto: bob@ejemplo.org>informe
error</a></xi:fallback>
</xi:include>
</xi:fallback>
</xi:include>
</div>
Si no se dispusiera de e3emloRolvidado#t!t, el documento resultante sera:
128
<?xml version=`1.0?>
<div>
<a href="malito:bob@ejemplo.org>Informe error</a>
</div>
K#2# XLin9. *ntroduccin & Concetos b=sicos
K#2#1# +l roblema a resolver
Para situar la necesidad de disponer de enlaces especializados entre documentos
XML, consideremos un ejemplo que se ha hecho habitual en la bibliografa XML,
consistente en tratar de gestionar un concurso canino en Internet desde la direccin:
www.concursocanino.com. En l los ejemplares de perros son valorados por distintos
jueces, basndose stos para su tarea calificadora en distintos datos y fotos, la
identificacin del propietario, las diferentes caractersticas d cada animal y un
mximo de cinco fotografas (dos obligatorias, de frente y de perfil y tres
opcionales).
Al disear el documento de cada participante el elemento principal sera erro con
un atributo id que lo identifica con un nmero, y teniendo como elemento hijo:
nombre(s), gnero del animal, da de nacimiento, raza, juez, dueo y fotos. Ello lo
podramos escribir, con los recursos de XML que conocemos hasta ahora, como:
<concursocanino>
<perro id="0002>
<nombre tipo="formal>Drokkytshang Nying</nombre>
<nombre tipo="mascota>Kim</nombre>
<genero>masculino</genero>
<fechanacimiento>25-diciembre-2000</fechanacimiento>
<raza cdigo="tibm>
Tibetano Mestizo
</raza>

<juez pgina="http://xml.concursocanino.com/jueces.html#bobhayes>
Bob Hayes
</juez>
<dueo>
<dueonombre>Liz Bartlett</dueonombre>
<direccion norevelar="ocultar/>
<email>Khyri@idyllmtn.com</email>
</dueo>
129
<foto src="http://xml.concursocanino.com/imgenes/0002-01.jpg
alt="Vista Cabeza />
<foto src="http://xml.concursocanino.com/imgenes/0002-02.jpg
alt="Vista Lateral />
<foto src="http://xml.concursocanino.com/imgenes/0002-03.jpg
alt="Otra Vista />
</perro>
</concursocanino>
Observemos que este documento tiene grandes limitaciones que hacen que diste
mucho de cubrir las necesidades de un concurso de Internet con las condiciones
planteadas. Algunas de estas limitaciones son:
- Los atributos a'ina del elemento 3ue7 y el atributo src del elemento (oto
para ser realmente funcionales deberan poder ser procesadas como URIs.
- El comportamiento y el papel de los enlaces no queda establecido en el sentido
que nose indica si debe mostrarse en lnea, en una nueva ventana , etc.
- No parece razonable que haya que repetir los datos del propietario cada vez
que se produzca el alta de un perro en el concurso.
- Si funciona una aplicacin que usara el cdigo de raza para crear un enlace
con la pgina de razas de concurso, parece ms razonable incluirla
explcitamente en la estructura de datos que requerir una tabla especial para
ello.
- Etc.
Se notar que alguna de estas carencias se superan fcilmente incluso con el uso de
HTML, donde s es posible crear una relacin explcita entre un documento (o una
parte de l) incluyendo incluso las correspondientes fotos. Ello pone en evidencia la
necesidad de contar con una tecnologa para que XML pueda emular, y en su caso
superar a HTML.
Sirva esta introduccin para situar el tipo de problemas a los que se enfrenta
XLink dentro del entorno XML, que no son otros que cubrir y superar para
documentos XML las posibilidades existentes HTML en materia de enlaces entre
documentos.
K#2#,# Concetos de XLin9
130
En XML se entiende por enlace a toda relacin entre uno o ms recursos (o
porciones de ellos que se dice participan en el enlace. En trminos de esta
participacin se distingue entre recursos locales y remotos, donde un recurso se
llama local si participa en el enlace de forma que l mismo, o su elemento padre, lo
hace de forma explcita y se habla de recurso remoto cuando el recurso participa en
el enlace como resultado de la indicacin de una URIref. Como consecuencia de esta
distincin, en un enlace se dice que un recurso local se especifica "por valor y un
recurso remoto se especifica "por referencia.
En cuanto a los enlaces en s mismos, se distinguen dos tipos: simples
(unidireccionales desde un recurso local a un nico recurso remoto) y complejos
(con relaciones ms extensas y mltiples), forma que en estos ltimos se pueden
dar relaciones bastante diferentes, tales como:
- Definir enlaces bidireccionales (incluso cuando no se controle los recursos
enlazados)
- Definir enlaces mltiples que relacionen ms de un recurso de inicio y/o ms
de un recurso final
- Crear relaciones con papeles especficos para cada recurso.
- Definir un enlace que hace de tercera parte para describir relaciones entre
recursos remotos.
- Referenciar una base de enlaces o linkbase (que es la forma como se conoce a
un conjunto de recursos relacionados entre s) con terceras partes, como
anotaciones o ndices.
- Etc.
Las ventajas que comportan el uso de enlaces complejos respecto de los simples
residen en que manejan un conjunto de propiedades (que llamaremos arcos) que
definen con mucha mayor decisin las relaciones existentes entre los distintos
componentes de los enlaces. Concretamente, se llama arco a la descripcin del
enlace, lo que incluye:
- Recurso del inicio
- Recurso final
- Sentido entre los recursos
- Informacin adicional sobre el comportamiento que se produce al activar el
enlace
131
Con todo ello debe entenderse que una vez identificados los recursos, las relaciones
entre ellos quedan debidamente especificadas mediante la definicin del arco.
El proceso de activar una relacin en un enlace se conoce como atravesar
(traversing) el enlace, cosa que obviamente depende de cada aplicacin, donde el
autor debe especificar su significado y comportamiento a travs de una serie de
atributos que veremos a continuacin.
K#5# +lemento en XLin9
De forma aparentemente chocante, el espacio de nombres de XLink (al que se
asocia el prefijo !lin9)carece de elementos predefinidos, ya que se da la
significativa novedad de que todo elemento XML puede declararse elemento XLink
simplemente aadindole el atributo !lin9.t&e% pudiendo, a continuacin,
adjuntarle todos los atributos adicionales que sean necesarios para especificar sus
propiedades dentro del enlace. Esta libertad para definir elemento objetivo de enlace
constituye una diferencia radical de los enlaces de HTML, donde slo determinados
elementos pueden contener enlaces.
+l ael & valores de !lin9.t&e
Partiendo del hecho de que tericamente todo elemento XML puede ser un elemento
XLink, veamos la sintaxis para incorporar a cualquier elemento los atributos propios
del enlace, que necesariamente son atributos lo*ales. En el ejemplo sigue, el
elemento !re( crea un enlace simple entre el trmino "WAI y el "site de la
Iniciativa de Accesibilidad del Web de W3C:
<xref abbrev="Iniciativa de accesibilidad del Web
xmlns:xlink="http://www.w3.org/1999/xlink/
xlink:type="simple
xlink:role="http://xml.kynn.com/linkprops/crossref
xlink:href="http://www.w3.org/WAI>
</xref>
Donde xref es un elemento XLink en virtud de los atributos !lin9.t&e: este
elemento viene caracterizado por !lin9.hre( & !lin9.role que hacen referencia al
espacio de nombres correspondiente. Obsrvese cmo en este ejemplo se ha
incorporado tambin un atributo ajeno a XLink, abbrev (que indica la expansin
acrnima del termino referenciado) para poner de manifiesto que es perfectamente
posible aadir a un elemento XLink atributos que no tengan que ver con el propio
enlace. Debe insistirse en que se est trabajando con un elemento XML genrico, y
132
en consecuencia, no existe razn alguna para que un elemento XLink pueda
contener atributos que no sean propios de XLink, que soportan su propio papel
dentro del documento XML, aunque no estn relacionados con ninguna funcin
relacionada con el enlace.
El papel del atributo !lin9.t&e es obviamente clave, ya que determina la funcin
que va a jugar cada elemento dentro de la estructura que proporciona XLink, y
existen seis posibles valores para l: simle (enlace simple), e!tended (enlace
complejo), locutor (recurso remoto en un enlace complejo), resource (recurso local
en un enlace complejo), arc (relacin entre recursos en un enlace complejo), y title
(informacin sobre un enlace, legible por humanos). Como se observa de la relacin
anterior, en el caso de los enlaces simples, el atributo !lin9.t&e toma un solo valor
mientras que para el caso de los enlaces complejos, estos valores se corresponden
con situaciones bastante distintas, que deben ser debidamente especficas. Veamos
estos seis posibles valores ms detalladamente:
4imle. Es la forma ms sencilla de un enlace. La relacin que se define
unidireccional desde un recurso local a uno remoto. Son ejemplos de enlaces
simples:
<hyperlink xmlns:XLink="http://www.w3,org/1999/xlink
xlink:type="simple
xlink:href="http://www.webaim.org/>
Accesibilidad a la Web como objetivo
</hyperlink>
<image xmlns:xlink="http://www.w3.org/1999/xlink
xlink:type="simple
xlink:href="mifoto.jpg
XLink:title="Mi Foto/>
+!tended. Este valor define un enlace complejo, y consiste en un elemento tpico
e!tended, con varios elementos hijos que definen tanto los tipos de recursos que
intervienen, como las relaciones entre ellos. Estos recursos pueden ser tanto locales
como remotos; los primeros se identifican por un elemento tipo resource con el
contenido del enlace, y los segundos mediante un elemento tipo locutor. Por tanto,
e!tended define un enlace complejo asociando una combinacin arbitraria de
recursos locales y remotos. Por ejemplo:
<concursocanino>
xmlns="http://xml.concursoperros.com/perroML-5.dtd>
<perro xlink:type="extended>
<perroinfo id="0002>
....
133
</perroinfo>
....
</perro>
</concursocanino>
Locator. Como se ha dicho, indica un recurso remoto dentro de un enlace complejo,
y por tanto debe tener significado por s mismo; por ejemplo:
<enlaceextendido
xmlns:xlink="http://www.w3.org/1999/xlink xlink:type="extended>
<XXX_locator xlink:type="locator
xlink:href="http://www.XXX.org/xxl/XSLTreference/Salida/indice.html>
</XXX_locator>
</enlaceextendido>
0esource. Especifica los recursos locales que participan en el enlace complejo,
pudiendo tener en principio cualquier contenido (incluso puede no tenerlo) siendo
uno de los usos de este valor el poder indicar la participacin de un determinado
recurso local dentro de un enlace complejo, por ejemplo:
<relacin xmlns:xlink=http://www.w3.org/1999/xlink
xlink:type="arc
xlink:from="Zeus
xlink:to="apolo
</relacion>
Title# Este servidor tiene con contenido una descripcin legible por humanos, sin
que tengan ningn significado para el enlace complejo que lo contiene.
<fotolink xlink:form="perroinfo
xlink:to="foto 3
xlink:title="vista cebeja/>
K#8# Atributos en XLin9
Con lo dicho, ante la evidencia de cualquier uso de XLink descansa bsicamente en
los atributos que incorpora, a la hora de presentar estos atributos que incorpora, a
la hora de presentar estos atributos vamos a distinguir por un lado aquellos cuya
funcionalidad slo tiene sentido para los enlaces complejos.
Conviene adelantar que gracias a las prioridades de las DTDs y de los Esquemas,
los valores de los atributos se pueden asignar por defecto, de forma que al
134
especificar los atributos en XLink es perfectamente posible declarar valores por
defecto para ellos, con lo que se evita tener que escribirlos para cada elementos
particular, ya que el analizador los incluye automticamente cuando procesa la DTD
o el Esquema. Con ello se abrevia la escritura y se reduce sensiblemente los
atributos a escribir, pues aquellos atributos que sean fijos no necesitan reescribirse
en el documento instancia.
K#8#1# +n enlaces simles
Aunque por motivos de simplicidad los atributos de esta seccin se presentan en el
marco de los enlaces simples, son igualmente vlidos en el marco de los enlaces
complejos. Los ms significativos son:
!lin9.hre(: tiene como misin referenciar cualquier recurso externo usado
(imgenes, archivos script, presentaciones multimedia, etc.) pudiendo tomar como
valores bien URIs vlidas (con la notacin de escapes que permitan su inclusin en
archivos XML) o bien expresiones XPointer cuando se hace referencia a documentos
o parte de ellos. As en el caso del dueo de los perros del concurso:
<dueo xlink:type="simple
xlink:href="http://xml.concursocanino.com/show.php?
dueo=khyri@idyllmtn.com
####...##
!lin9.role. proporciona metainformacin relacionada con el papel semtico del
correspondiente elemento; su valor debe ser una URI, obligatoriamente absoluta,
que tiene el doble papel de actuar como un identificador nico cuyo objetivo es
proporcionar informacin de una forma similar a como lo hace el espacio de
nombres, al tiempo de actuar como una referencia a un documento explicativo del
significado del valor. Este atributo slo se aplica en enlaces y recursos (para lo que
es opcional), ya que para el resto de tipos no tiene sentido. En el ejemplo canino:
<dueo xlink:type="simple
xlink:href="http://xml.concursocanino.com/show.php?dueno=khyri@idyllmtn.com
xlink:role="http://xml.concursocanino.com/linkprops/dueo
..##
indica la pgina donde constan los datos de los dueos de los dueos de los perros
que estan en concurso.
!lin9.arcrole: parecido a !lin9.role tiene como objetivo proporcionar
metainformacin relacionadas con las propiedades de la relacin entre dos o ms
135
recursos. Considrese el enlace entre dos libros, donde se quiere indicar que uno es
continuacin del otro; el papel o "role de cada uno se identifica con una URI que
identifica el significado de "libro, y se puede dar un "arcrole entre ellos acerca de
lo que es una "continuacin (en la direccin del primer al segundo libro);por
ejemplo:
<datoslibro>
<titulolibro>La Comunidad del Anillo</titulolibro>
<autor>JRR Tolkien</autor>
<relacionado xmlns:xlink="http://www.w3.org/1999/xlink
xlink:type="simple
xlink:href="http://xml.kynn.com/libro.php?isbn=0553579908
xlink:role="http://xml.kynn.com/linkprops/book
xlink:arcrole="http://xml.kynn.com/linkprops/continuacin>
Las Dos Torres
</relacionado>
</datoslibro>
Otros atributos de XLink que son necesarios conocer:
!lin9.title (no confundir con !lin9.t&e con valor tittle, del cual en cierta manera
es una generalizacin): se utiliza para proporcionar un ttulo legible accesible al
usuario que puede asociarse opcionalmente a todo elemento XLink.
!lin9.shoP: permite definir la forma en que debe mostrarse una relacin XLink, de
forma que este atributo responde a la pregunta: Qu hacer con esto? Conviene
saber que XLink define cinco valores para ello: new, replace, etc.
!lin9.actuate: una vez especificado con el atributo anterior lo que hace con la
relacin, el atributo !lin9.actuate responde Cundo lo hago?. Sus valores son:
onLoar, onRequest, other nome.
Un ejemplo del uso conjunto de estos ltimos tres atributos es:
<dueo xlink:type="simple2
xlink:href="http://xml.concursocanino.com/show.php?dueo=khyri@idyllmtn.com
xlink:role="http://xml.concursocanino.com/linkprops/dueo
XLink:title="Dueo Liz Bartlett
xlink:show="replace
xlink:actuate="onRequest />
cuyo significado es bastante evidente.
136
K#8#,# Atributos roios de los enlaces comle3os

Adems de los atributos comunes con los enlaces simples, existen atributos
especficos de los enlaces complejos. Algunos ejemplos de estos atributos son:
!lin9.label: su objetivo es etiquetar los valores de tpicos complejos locator y
resource para identificarlos como integrantes de un arco determinado. Sus valores
son tipo 1MTOT+1, lo que significa que deben empezar por una letra y contener
letras y nmeros (sin espacios en blanco o puntos entre ellos). Debe sealarse que
en un enlace mltiple es perfectamente posible que los recursos y localizadores
involucrados en l puedan compartir los mismos valores de este atributo, ya que los
arcos definidos a partir de tales etiquetas se definen por el origen o destino de sus
elementos. Siguiendo con el ejemplo del concurso canino, supngase que se quiere
crear un nuevo elemento (erroin(o)hijo del elemento erro con informacin
especifica acerca de un determinado anima. Para ello se puede escribir:
<perroinfo id="0002
xlink:type="resource
xlink:role="http://xml.concursocanino.com/linkprops/perroinfo
xlink:label="perroinfo>
<nombre tipo="formal>Drokkytshang Nying</nombre>
<nombre tipo="mascota>Kim</nombre>
<genero>Masculino</genero>
<fechanacimiento>25-Diciembre-2000</fechanacimiento>
</perroinfo>
!lin9.(rom y !lin9.to: definen los recursos inicial y final de la relacin descrita por
un enlace complejo, y no son necesarios en un enlace simple pues en este caso el
propio contenidota define este inicio y final. Ntese que los atributos (rom y to slo
aparecen sobre elementos tipo arc.
Sus posibles valores son cualquier etiqueta que haya sido asignada a un tipo
locator o resource con el mismo !lin9.label. En el caso de que hubiera ms de un
elemento locator o resource con el mismo !lin9.label, el elemento que incorpora
!lin9.(rom identifica las relaciones con origen en todos estos recursos y lo mismo
ocurre respecto a !lin9.to y los recursos finales. Sealar que es posible que existan
arcos con el mismo recurso para !lin9.(rom y !lin9.to, en cuyo caso el recurso se
enlaza consigo mismo.
En el caso de que algunos de estos dos atributos no tuviera especificado ningn
valor, hay que interpretarlo en el sentido de que la relacin de la que forman parte
existe desde (para el caso de from) o hasta (para el caso de to) todos los elementos
137
con locator o con 0esource que estn presentes dentro del correspondiente enlace
completo.
K#K# Las osibilidades de XLin9

Con el nico objetivo de sealar alguna de las ventajas que ofrece XLink, vamos a
sealar algunas mejoras que son susceptibles de incorporarse al ejemplo que hemos
presentado en la seccin 6.3 en el que hemos detectado importantes carencias que
vamos a tratar de superar. As, parece razonable plasmar el hecho de que tanto
jueces como propietarios son personas, por lo que cabe definirlas de la misma
forma, y tiene sentido eliminar las diferencias entre 3ue7 y dueNo, reescribiendo
para ello un nico elemento humano de forma que la relacin exacta entre enlaces
que existan entre erro% duelo & 3ue7% que quedaran documentados a travs del
atributo arcrole. As con un DTD por defecto adecuado, se puede escribir:
<concursocanino
xmlns="http://xml.concursocanino.com/perroML-5.dtd>
<! - con xlink extendidos y atributos por defecto ->
<perro xlink:type="extended>
<perroinfo id="0002>
<nombre tipo="formal>Drokkytshang Nying </nombre>
<nombre tipo="mascota>Kim</nombre>
<genero>Masculino</genero>
<fechanacimiento>25-Diciembre-2000</fechanacimiento>
</perroinfo>
<raza xlink:href="http://xml.concursocanino.com/raza.php?codigo=tibm
xlink:title="Tibetan Mastiff />
<humano
xlink:href="http://xml.concursocanino.com/jueces.html#bobhayes
xlink:title="Bob Hayes
xlink:label="bobhayes />
<humano>
xlink:href="http://xml.concursocanino.com/show.php?dueno=Khyri@idyllmtn.com
xlink:title="Liz Bartlett
xlink:label="lizbartlett />
<foto xlink:href="http://xml.concursocanino.com/imagines/0002-01.jpg
xlink:label="foto1 />
<foto xlink:href="http://xml.concursocanino.com/imgenes/0002-02.jpg
xlink:label="foto2 />
<foto xlink:href="http://xml.concursocanino.com/imgenes/0002-03.jpg
xlink:label="foto3 />
<perrolink xlink:arcrole="http://xml.concursocanino.com/linkprops/esraza
138
xlink:from="perroinfo
xlink:to="to
xlink:title="Raza />
<perrolink xlink:arcrole="http://xml.concursocanino.com/linkprops/juzgadopor
xlink:from="perroinfo
xlink:to="bobhayes
xlink:title="Juez />
<perrolink xlink:arcrole="http://xml.concursocanino.com/linkprops/duenoes
xlink:from="perroinfo
xlink:to="lizbartlett
xlink:title="dueo />
<fotolink xlink:from="perroinfo
xlink:to="foto1
xlink:title="vista cabeza />
<fotolink xlink:from="perroinfo
xlink:to="foto2
xlink:title="vista lateral />
<fotolink xlink:from="perroinfo
xlink:to="foto3
xlink:title="otra vista />
</perro>
</concursocanino>
Notemos que el anterior listado sigue siendo mejorable, como por ejemplo,
definiendo accesos a las URI usando !ml.base en combinacin con la
correspondiente DTD o Esquema, ya que con ellos se obtienen nuevos arcos.
Adems es factible incorporar enlaces desde recursos remotos (identificados por
locators como humano) a un recurso local (erroin(o) pudindose especificar que
estos enlaces vayan en ambos sentidos. Incluso se pueden incluir enlaces de
terceras partes (establecidos por arcos como podran ser ro!ima(oto y rev(oto
que no vamos a definir por razones de brevedad) que determinan un orden para
navegar entre las fotos y que se podran usar para incluir fotos adicionales.
No es nuestra misin optimizar y refinar la programacin, sino simplemente poner
de manifiesto las posibilidades que ofrece XLink a la hora de manejar enlaces en el
seno de los documentos XML. Como resumen conclyase que XML cuenta con
tecnologas y condiciones para explotar todas las posibilidades que encierra el
concepto de enlace, superando incluso las posibilidades que ofrece HTML.
Terminaremos diciendo que XLink juega un papel muy importante en
determinados lenguajes basados en XML, de los cuales cabe citar XBBL (Extended
Business Report Language) que se est imponiendo en el intercambio de informacin
que se produce en los entornos contables y financieros.
139

J CAPTULO
Consultas en XML. X;uer&
7.1. Recuperacin de informacin de documentos XML
7.2. Introduccin a XQuery
7.3. Conceptos de XQuery
7.4. Recorrer y construir rboles en XQuery
7.5. Cambiar y restaurar informacin
7.6. Operar en XQuery
J#1# 0ecueracin de in(ormacin en documentos XML#
Cualquiera que sean los datos que se almacenan, si se hace en formato XML, su
estructura se simplifica como consecuencia de los principios de orden y jerarqua
que incorpora todo documento XML. Ello permite representar muchas clases de
datos, incluso aquellos procedentes de fuentes no XML.
Al hablar de introducir el tema de la consulta en un documento XML es obligacin
analizar las posibilidades que existen de emular en este terreno, las posibilidades
que conocemos existen con el uso de SQL en el modelo relacional, que es la gran
referencia de informtica para la consulta de datos. Vamos a resear las diferencias
existentes entre datos XML y datos racionales:
a) Metadatos: los datos relacionales presentan estructuras regulares y
homogneas (cada fila tiene las mismas columnas con los mismos nombres y
tipos) lo que permite usar metadatos sin ningn problema, mientras en XML los
datos son heterogneos e irregulares (pgina Web, captulo de libro, etc.) con
estructuras diferente que deben describirse caso a caso, de forma que estos
140
metadatos se acaban describiendo por propio dormitorio en el propios
documentos.
b) Anidamiento: los documentos XML contienen distintos niveles de anidamiento,
que son irregulares e impredecibles, mientras que los datos relacionales son
"planos al estar organizados a partir de tabla.
c) Derar(u+a: en XML existe una jerarqua y un orden intrnseco que no se da en la
estructura relacional, ello se refleja en la forma de trabajar de XPath ("el quinto
objetivo rojos, "los objetos que estn despus de A y antes de X, etc.)
cuando este orden y esta jerarqua carece de relevancia en el modelo
relacional.
d) 7ensidad: los datos relacionales son densos (cada columna un valor) y los
inexistentes se declaran como tales (con null), en cambio los datos en XML son
dispersos, y la informacin que no existe sencillamente carece de elemento.
Como consecuencia XML es ms libre que el modelo relacional a la hora de
enfrentarse con dalos faltantes.
e) Mecanismo de consulta: en XML el resultado de una consulta inevitablemente
en una secuencia heterognea de elementos, atributos y valores primitivos, que
a su vez puede servir de intermediarios para procesar una expresin de mayor
nivel, cosa que difiere de SQL, donde toda expresin dentro de una consulta
devuelve una tabla. Ello significa que un lenguaje de consulta para XML debe
proporcionar necesariamente funciones constructoras que sean capaces de
crear en el proceso estructuras anidadas que pueden ser complejas; se trata de
requisitos que en cambio son irrelevantes en el caso relacional con el uso de
SQL.
Ante las consideraciones anteriores, que conducen a la conclusin de que no siempre
las cosas que pueden ser objeto de consulta de un documento lo puedan ser en una
Base de Datos relacional y viceversa, W3C decidi que las consultas en XML deban
ser objeto de un nuevo lenguaje, se llam XQuery.
J#,# *ntroduccin a X;uer&
Mientras que en la informtica consultar es acceder a datos ya almacenados sin que
durante el proceso se cree otra cosa que no sea el propio resultado de la bsqueda,
en el caso de XML, no slo se consulta en el concepto habitual, sino que adems se
obtiene un fragmento de XML como resultado de ello. En consecuencia, una
consulta XQuery tiene como entrada y salida sendos documentos XML, con lo que
ste no es slo un lenguaje de consulta que opera sobre documentos (para ser ms
141
precisos, sobre instancias de un modelo de datos XML) sino que tambin genera
documentos XML a demanda de la consulta correspondiente. Por ello, los requisitos
puestos por W3C a XQuery son:
Clausura del modelo: toda consulta y todo resultado debe obedecer a un mismo
modelo de datos, esto es: "ser cerrado respecto al modelo de datos XQuery.
Compati*ilidad con los )s(uemas: ello supone disponer tanto de un conjunto de
tipos primitivos como de la posibilidad de definir nuevos tipos, con un mecanismo
que adems incorpore el correspondiente proceso de validacin.
Compati*ilidad con ;@ath: al basarse en este lenguaje de localizacin de la familia
XML, se pueden identificar las partes de un documento y con ello recuperar la
informacin deseada.
@osi*ilidad de Composicin: la totalidad de las distintas expresiones basadas en
XPath sean condicionales o cualquier otra, deben poder combinarse entre ellas con
la mxima generalidad. Ello significa en la prctica, que el resultado de cualquier
expresin se debe poder usar como operando de otra.
Completitud: aunque sin conseguir una potencia expresiva comparable a la
completitud del modelo relacional, XQuery debe ser capaz de obtener un documento
XML construido a partir de documentos diferentes, siempre usando para ello el
clculo de predicados de primer orden y las funciones recursivas.
1eneralidad: el lenguaje debe poder aplicarse tanto en entornos que usen tipos de
datos muy estrictos y bien especificados, como en otros, donde los tipos de entrada
y salida se descubran en tiempo de ejecucin, e incluso con datos que carezcan de
cualquier tipado. En otras palabras, XQuery debe poder trabajar con documentos
descritos de forma muy distintas, sea un Esquema, una DTD o incluso carecer de
cualquier descripcin.
Eemntica: no deben existir grandes restricciones semnticas a la hora de
proporcionar el resultado de una consulta. Esta exigencia es debida al hecho de que
la obtencin de un "valor en estas consultas puede consistir en ninguno, uno o
muchos tems, que a su vez pueden ser elementos, atributos o valores primitivos, lo
que hace que sea necesario que todo operador XQuery tenga bien definidas todas
las posibilidades que puedan aparecer.
El cumplimiento de lo anterior conduce inevitablemente a una semntica compleja,
y al objeto de simplificarla en XQuery se definen operadores con operaciones
implcitas. As por ejemplo, los operadores aritmticos que se utilicen (como +)
cuando se aplican a un documento, automticamente extraen su valor numrico,
mientras que por su parte los operadores de comparacin (como =) aplicados a una
142
secuencia de valores, de forma automtica, iteran buscando valores que satisfagan
la comparacin. Como puede verse se trata de trabajar con los mayores grados de
libertad posibles en la semntica a la hora de efectuar una consulta.
Anlisis esttico: asumiendo que el proceso de consulta tiene dos fases: anlisis y
evaluacin (parecido a la compilacin y ejecucin de un programa.) en XQuery se
optimiza el anlisis y el proceso de deteccin de errores, decidindose
automticamente qu errores se permiten y cules no.
De estos requisitos se constata que el objetivo de XQuery se centra mucho ms en
la recuperacin de informacin que en la actualizacin de documentos ya existentes,
por lo que en la prctica las consultas XQuery tienden a ajustarse a las tareas que
puedan interaccionar con aquellas cosas que ya estn almacenadas siguiendo la
sintaxis de XML.
J#2# Concetos de X;uer&
El modelo de datos de XQuery se basa en representar los datos de XML en forma de
nodos y valores, que sirven de operandos y resultado de los operadores XQuery. En
este modelo se representa uno o ms documentos XML con una secuencia definida
como una coleccin de uno o ms tems, donde un )tem es un nodo o un valor
atmico. Dos caractersticas importantes son:
1) Los nodos en XQuery se corresponden con los siete nodos del modelo XPath
(documento, elemento, atributo, etc.)
2) Los valores atmicos usados a corresponden con los tipos simples predefinidos
de los Esquemas (cadenas, booleamos, decimales, etc.).
En los modelos XQuery cada nodo elemento o atributo consta de:
- nombre (una cadena)
- anotacin de tio
- valor tiado, tal como lo determina el proceso de validacin en Esquemas y
en el caso de que estuviera sin validar o sin tipo adopta la anotacin
!s.an&T&e.
como se observa, el modelo XQuery se apalanca en la estructura XML que ya
conocemos, de forma que toda consultase basa en el rango de datos que usa el
documento analizado, esto es, un rbol etiquetado y ordenado, cuyos nodos tienen
una identidad que puede estar asociada a tipos de datos simples o complejos. Ello
143
permite que XQuery pueda usarse tanto para consultar documentos con datos sin
tipar, como gobernados por Esquemas, o aquello que obedece a una DTD.
XQuery es un lenguaje funcional cuya sintaxis es la de XML aunque parecida a la
de XPath, con lo que toda consulta es una expresin que debe evaluarse.
Adelantemos que una consulta acerca de todos los ttulos de los captulos de un
documento como libro#!ml, se puede hacer con la expresin tal como:
doc(" libro.xml )//capitulo/titulo
Como era lgico pensar, una expresin XQuery puede estar compuesta de otras de
ms bajo nivel que se combinan mediante operadores y palabras clave, de forma
que tras su anlisis, toda expresin acaba siendo una secuencia heterognea de
nodos y valores atmicos.
J#2#1# $e(iniciones b=sicas
Un literal es la clave ms simple de expresin XQuery, y representa un valor
atmico. En consecuencia sus valores se corresponden con los tipos simples de
etiqueta, donde los tipos numricos son xs:integer, xs:decimal, y xs:double y los
tipo cadena se delimitan por comillas pudiendo contener referencia a entidades
predefinidas.
Una varia*le en XQuery es un nombre que empieza con el signo dlar
($Capitulo)que se asocia a un valor y que se usa dentro es una expresin para
representarlo. Una forma de dar valores a una variable es por medio de una
expresin let que asocia una o varias variables y luego evala la correspondiente
expresin interna.
Un constructor es una funcin que crea un valor de un tipo particular a partir de
una cadena que contiene la representacin lxica del tipo deseado; por ejemplo:
string($Capitulo/numero)
Los distintos tipos de valores atmicos se crean llamando a un constructor, que en
general tiene el mismo nombre que el tipo que construye.
Una transformacin es el paso de una instancia del modelo de datos a otra
instancia de este modelo, dejando abierto tanto el origen de los datos de entrada
como la forma como se enva el resultado a la aplicacin que haya invocado esta
transformacin.
144
Para identificar los datos de entrada existen dos funciones bsicas: docO@ que
devuelve un documento completo identificndolo con una URI; por ejemplo:
docOQlibros#!mlS@ y collectionO@ que devuelve cualquier secuencia de nodos
asociada a la URI (a menudo usada para identificar la base de datos empleada en la
consulta). Por tanto, una consulta puede tener su entrada bien por medio de doc%
collection, o bien referenciando alguna parte de un contexto externo. Se habla de
error dinmico si las funciones docO@ & collectionO@ no localizan lo especificado en
ellas.
Una consulta consta de dos partes: prlogo ((uery prolo) y cuerpo ((uery *ody).
El prlogo consta de una serie de declaraciones que definen el entorno para el
procesado del cuerpo, que consta de una expresin cuyo valor proporciona el
resultado de la consulta. El prlogo se usa cuando el cuerpo depende de lo espacios
de nombres, Esquemas o funciones, y cuando ello ocurre la consulta depende en
gran medida de lo especificado en l.
Como ejemplo de la forma de trabajar, sea el documento XQueryLibro.xml:
<xml version=`1.0?>
<Libro>
<Titulo> Respuestas XQuery </Titulo>
<Capitulo numero="1 titulo="El primer Capitulo>
..
</Capitulo>
<Capitulo numero="2 titulo="El segundo Capitulo
..
</Capitulo>
<! - y continua con ms captulos . - >
</Libro>
y veamos cmo obtener el sumario con el nmero y ttulo de cada captulo, cosa que
podemos hacer mediante:
<tablacontenidos>
{
FOR $Capitulo IN doc("XQueryLibro.xml)//Capitulo
RETURN
<CabeceraCapitulo>
<string($Capitulo/@numero)}..{string($Capitulo/@ttulo)}
</CabeceraCapitulo>
}
</Tablacontenidos>
145
donde se observa cmo tras la etiquete de inicio de elemento Tablacontenidos se
crea la variable _Caitulo a la que se asigna una secuencia de nodos con el uso de
la palabra clave: IN que precede del documento que proporciona esta secuencia,
terminando con 66Caitulo que selecciona cualquier elemento Caitulo del
documento objeto de la consulta. Por su parte, la sentencia 0+TU01 define la salida
para cada nodo que aparece en la secuencia definida por la variable _Caitulo#
A continuacin, para cada nodo elemento Caitulo se indica el literal de la
etiqueta de comienzo CabeceraCaitulo y como primera salida, la expresin
{string($Capitulo/@numero)} que obtiene el valor del atributo numero del
elemento Caitulo. Al existir en el documento dos elementos Caitulo, la consulta
produce dos elementos CabeceraCaitulo cuyo contenido son los valores de los
atributos numero y titulo de cada elemento Caitulo del documento fuente. El
resultado es el fragmento:
<Tablacontenidos>
<CabeceraCapitulo>
1..El Primer Capitulo
</CabeceraCapitulo>
<CabeceraCapitulo>
2..El Segundo Capitulo
</CabeceraCapitulo>
</Tablacontenidos>
J#2#,# Tios de datos en X;uer&
Puesto que un documento XML puede contener una gran variedad de informacin,
un lenguaje de consulta debe evitar todas las suposiciones previas que puedan
terminar generando conflictos con los datos que se vayan a encontrar; con ello, el
programador podr centrarse en el tratamiento del documento sin tener que entrar
en excesivas sutilezas acerca del sistema de tipos que maneje en cada caso.
Por ello, recordando los requisitos puestos a XQuery, ste debe estar en
condiciones de poder procesar documentos tan distintos como:
- Los tipados con Esquemas, lo que supone contar con un lenguaje de consulta
con datos estticos fuertemente tipados, lo que evita un gran nmero de
errores.
- Los gobernados por otros lenguajes de esquema como DTDs.
146
- Los usados con una visin procedente de otro sistema no XML, como sera el
caso de un Sistema de Gestin de Base de Datos relacional.
Obsrvese que las fuentes de datos pueden tener estructuras muy complejas, y por
ello las expresiones deben estar bien definidas para que se est en condiciones de
poder evaluar cualquier estructura. Por ello, XQuery se especifico para trabajar con
datos poco o muy tipados, siendo su sistema de tipos uno de sus aspectos ms
tiles, eclcticos e inusuales que existen. Como conclusin, retngase que para
encarar esta variedad de situaciones, XQuery permite escribir consultas con muy
poca informacin sobre tipos. Ello es factible gracias a la capacidad de XQuery para
obtener y utilizar la informacin de tipos en tempos de ejecucin, siendo capaz, a
pesar de ello, de poder detectar posibles errores antes de que la consulta se ejecute
del todo.
Si el documento XML manejado obedece slo a una DTD o incluso si carece de
cualquier esquema, los tipos son muy reducidos: documento, elemento, ID, IDREF,
etc., con lo que el documento incorpora poca informacin referida a tipos, y por ello
las consultas se hacen confiando en un conjunto de reglas, de manera que durante
el proceso de ejecucin se pueda inferir el tipo apropiado para poder obtener el valor
buscado. En cambio, cuando XQuery se enfrenta con tipos de datos derivados de
Esquemas XML, debe distinguir mucho ms, y en consecuencia debe estar en
condiciones de manejar, por un lado, los tipos predefinidos accesibles en toda
consulta, y por otro, los tipos importados para la consulta desde un Esquema
especifico. Esta flexibilidad de XQuery debe ser apreciada debidamente.
J#2#2# 4istemas de tios. X;uer& b=sico

Puesto que el sistema de tipos de datos de XQuery se basa en Esquemas, hay que
distinguir dos conjuntos desde un Esquema concreto. Se llama X;uer& :=sico al
mecanismo que admite por un lado la importacin de Esquemas para hacerlos
accesibles a la consulta, y por otro, la posibilidad de utilizar un tipado esttico que
permita que una consulta pueda contrastarse con los Esquemas importados, de
forma que se puedan localizar los posibles errores antes de acceder a los datos.
Es importante hacer notar que con el mecanismo XQuery bsico, una consulta no
necesita importar ningn Esquema para poder utilizar tipos predefinidos, ya que
estn contenidos en el propio documento, y el modelo de datos preserva esta
informacin de tipos, permitiendo con ello que las consultas accedan a ellos. As,
aunque una consulta no importe Esquema alguno, se pueden usar sin problemas los
correspondientes tipos simples que se encuentren presentes en los datos del
documento.
147
Los dichos no obsta para que en el caso de que la consulta utilice una lgica
relacionada con el significado de un Esquema, sea aconsejable proceder a su
importacin, cosa que para hacerse debe ser tenido en cuenta por la aplicacin que
vaya a generar la consulta. Hagamos notar que al ser secuencia los valores
habituales en XQuery, los tipos usados para describirlos se llaman tios secuencia,
que pueden ser bien tipos predefinidos, y por ello ser usados en cualquier consulta,
o bien estar definidos en un Esquema, los cuales deben importarse previamente.
Como se ha dicho, a las implementaciones XQuery se les requiere que detecten
errores de tipo, cosa que unas veces pueden hacerse antes de que se ejecute la
consulta y otras slo durante la ejecucin, cuando se evale la expresin
correspondiente. A la primera posibilidad se le llama tiado est=tico y se efecta
usando simultneamente la informacin importada y la propia de la consulta. Un
procesador dotado de tipado esttico por tanto puede detectar determinados tipos
de errores mediante la simple comparacin de la consulta con el Esquema
importado, lo que significa que no se requiere acceder a los datos para encontrar
tales errores.
J#2#5# Caacidades de X;uer&
Al objeto de reunir las potencialidades de XQuery, en lo que resta de captulos nos
enfrentaremos a tres apartados, cuya razn de ser ya hemos introducido:
- El manejo de los rboles de XQuery.
- La combinacin y reestructuracin de los documentos XML obtenidos.
- Los cuantificadores, operadores y funciones propias de XQuery.
Como ejemplo de referencia de este proceso usaremos el documento libro#!ml del
cual nos interesa el fragmento:
<bib>
<libro anyo="1994>
<titulo> TCP/IP Ilustrado </titulo>
<autor> <apellido>Stevens</apellido> <nombre>W.</nombre> </autor>
<editorial>Prentice-Hall </editorial>
<precio> 65.95</precio>
</libro>
<libro anyo="1992>
<titulo> Programacin Avanzada en el entorno Unix </titulo>
<autor> <apellido>Stevens</apellido> <nombre>W.</nombre> </autor>
148
<editorial> Prentice-Hall</editorial>
<precio>65.95</precio>
</libro>
<libro anyo="2000>
<titulo> Datos en la Web </titulo>
<autor> <apellido>Abiteboul</apellido> <nombre>Serge</nombre>
</autor>
<autor> <apellido>Buneman</apellido> <nombre>Peter</nombre>
</autor>
<autor> <apellido>Suciu</apellido> <nombre>Dan</nombre> </autor>
<editorial> Editorial Morgan Kaufmann </editorial>
<precio> 39.95</precio>
</libro>
<libro anyo="1999>
<titulo> Economa de la Tecnologa y el contenido de la TV digital </titulo>
<editor> <apellido>Gerbarg</apellido> <nombre>Darcy</nombre>
<afiliacin>CIII</afiliacin>
</editor>
<editorial>Editorial Kluwer Academia </editorial>
<precio>129.95</precio>
</libro>
</bib>
donde se describe una relacin bibliogrfica (bib) de cuatro libros con una
estructura de los elementos libro igual para todos a excepcin del ltimo que
incorpora el elemento editor en lugar de uno o ms elementos autor de los tres
primeros (recurdese que un editor se distingue de un autor en que siendo
responsable del libro, no es el autor del texto completo, ya que cada captulo suele
estar escrito por personas distintas).
NOTA: Aunque al expresar el documento libro#!ml que nos servir de ejemplo
en el resto del captulo lo hemos indentando como es habitual, al objeto de
distinguir lo que es el documento resultado de una consulta, tanto a unos como a
otras lo expresaremos sin identar.

J#5# 0ecorrer & construir =rboles en X;uer&
Para presentar las expresiones y operaciones bsicas que permiten retroceder y
construir rboles con XQuery, usaremos el marco de las distintas tareas a llevar a
cabo:
149
a) La localizacin de nodos utilizando expresiones basadas en trayectos
XPath.
b) La localizacin de estructuras XML usando constructores.
c) La extraccin de tipos.
J#5#1# Locali7acin de nodos en estructuras XML#
Para que XQuery cumpla su objetivo, sus expresiones deben poder localizar nodos
empezando por determinar el documento en el que efectuar la bsqueda. Por
ejemplo:
doc("libros.xml)/bib/libro
abre el documento libro#!ml obteniendo su nodo documento, con 6bib se
selecciona este elemento y con 6libro se obtienen estos elementos dentro de bib#
En el caso de que en proceso se vayan a necesitar variables, stas se definen en el
prlogo de la consulta, de forma que una vez declaradas son accesibles en cualquier
punto. As, si los ttulos de los libros en libro#!ml van a usarse varias veces en una
consulta, tiene sentido definir una variable, tal como: _t)tulos.
Los predicados XPath como mtodos para filtrar secuencias de nodos se
generalizan en XQuery de forma que el valor de una expresin siempre sea una
secuencia heterognea de nodos y valores atmicos. Son ejemplo de su
funcionamiento:
- doc("libros.xml)/bib/libro/autor[apellidos="Stevens] que devuelve slo los
autores cuyo apellido="stevens sea true.
- doc("libros.xml)/bib/libro/autor[1] que devuelve el primer autor de cada libro.
En la lnea de las expresiones XPath, una expresin en XQuery puede empezar con /
o //. En el primer caso la bsqueda se inicia en el nodo raz, mientras que el
significado del operador //, en trminos del modelo de datos, es dar acceso a todos
los atributos y descendientes de los nodos que aparecen en su izquierda en el
documento considerado; por ejemplo:
- doc("libros.xml)/bib ajusta el elemento bib a la raz del documento.
- doc("libros.xml)//libro de acceso a todos los elementos libro del documento.
150
- doc("libros.xml)//anyo localiza todos los atributos an&o en el documento.
- doc("libros.xml)/bib//autor[1] al presentar varios escalones sigue la
secuencia: primero devuelve el nodo documento, devuelve el elemento bib, a
continuacin devuelve todos los nodos que descienden de l y finalmente
seleccione el elemento primer autor para cada nodo contexto (ntese que slo
los elementos libro contiene al elemento autor).
Igual que en XPath, las "wildcards permiten que las consultas seleccionen sin
especificar sus nombres completos; por ejemplo:
doc("libro.xml)//libro[1]/*
obtiene los elementos del primer libro, donde * se ajusta a cualquier elemento, est
o no en el espacio de nombres, ya que las expresiones XQuery soportan espacios de
nombres, lo que permite distinguir nombres procedentes de vocabularios
diferente4s.
Hagamos notar debido a que durante el proceso de evaluacin de toda expresin
XQuery siempre se devuelven nodos del documento sealado, si en ella hubiera algo
que o correspondiera a uno de estos nodos aparecer un error de tio#
J#5#,# Construccin de estructuras XML

Una vez localizados los nodos en un documento, se debe crear el resultado que
satisface la consulta, cosa que se hace mediante el uso de constructores; esta
capacidad de construir nuevos objetos XML es una de las funcionalidades ms
importantes de XQuery. La sintaxis para ello se basa en la evaluacin de una
expresin que aparece entre llaves y que obviamente no tiene el mismo significado
que en la notacin XML, ya que mientras XQuery el smbolo {es el inicio de una
expresin a evaluar, en XML slo es un carcter. As,
<precio>123.45</precio>
es un elemento de nombre precio que contiene un literal, mientras que:
<precio >{$retail * 0.85}</precio>
es un elemento construido cuyo contenido se calcula evaluando una expresin.
151
Una vez proporcionando explcitamente un constructor por medio de { }, la
consulta se inicia creando un nodo documento que empieza siendo vaco y que
acaba rellenndose con el resultado correspondiente, hasta crear un documento
completo. Las expresiones delimitadas por { } siempre estn encargadas de evaluar
y crear contenidos de elementos o atributos; por ejemplo:
<ejemplo>
<p> Esta es una consulta </p>
<eg> doc("libros.xml)//libro[1]/titulo </eg>
<p> Este es el resultado de la consulta anterior.</p>
<eg>{ doc("libros.xml)//libro[1]/titulo }</eg>
</ejemplo>
produce el documento:
<ejemplo>
<p> Esta es una consulta. </p>
<eg> doc("libros.xml)//libro[1]/titulo </eg>
<p> Este es el resultado de la consulta anterior.</p>
<eg><titulo>TCP/IP Ilustrado</titulo></eg>
</ejemplo>
Las expresiones incluidas en los constructores de elementos permiten crear
nuevos valores XML reestructurando los existentes, como por ejemplo en una lista
de ttulos mediante:
<titulo count="{ count(doc(`libros.xml)//titulo) }>
{doc("libros.xml)//titulo}
</titulo>
se obtiene el documento:
<ttulos count = "4>
<titulo>TCP/IP Ilustrado</titulo>
<titulo> Programacin Avanzada en el entorno Unix </titulo>
<titulo>Datos en la Web</titulo>
<titulo>Economa de la Tecnologa y el contenido de la TV digital</titulo>
</titulo>
Debe hacerse notar, aunque no mostremos ningn ejemplo, la posibilidad
existente de enlazar constructores de forma sucesiva, creando con ello constructores
sucesivamente ms complejos que van anidando elementos y atributos.
152
J#5#2# +!traccin de tios
En un lenguaje de bsqueda, los tipos de datos permiten comprobar la correccin
tanto de la propia consulta como de las operaciones a los que se va a someter los
datos de la respuesta; en base a ello, XQuery aprovecha que los Esquemas XML
proporcionen un conjunto de tipos predefinidos y la posibilidad de definir nuevos
tipos para manejar los tipos de datos involucrados en una consulta. Por ello, en el
prlogo de toda consulta deben figurar explcitamente los Esquemas que se van a
importar, identificndolos por su espacio de nombres, de forma que durante el
correspondiente proceso de validacin los nodos elementos y atributos puedan
adquirir sus notaciones de tipo correspondientes. Recordemos de que no se usen
Esquemas, todos los nodos elementos tienen por defecto como notacin tipo
!s.an&T&e.
La consecuencia a retener es que la falta de definicin de tipos no impide que se
puedan efectuar consultas con XQuery; por ejemplo:
avg( doc("libros.xml)/bib/libro/precio)
calcula el precio medio de un libro en nuestro ejemplo, aunque no haya Esquema
alguno involucrado, ni el elemento recio est tipado. Para ello sea posible, cuando
av'O@ requiere un argumento numrico, automticamente cada valor de recio se
convierte a doble precisin y se calcula la medida requerida.
Esta conversin implcita siendo muy til cuando se trabaja con datos no tipados
puede no ser ptima, como en el caso del ejemplo que se acaba de ver, donde el
precio se representara mucho mejor por un decimal. Obviamente, si es el proceso
de consulta existiese un Esquema que declarase recio como decimal, la medida se
calculara usando nmeros decimales.
Consecuencia de lo anterior es la necesidad de conocer la forma como XQuery
trata las distintas casusticas que pueden aparecer durante el proceso de un
documento. As, por ejemplo, si nos encontramos con una expresin como: 1` _b,
hay que preguntarse cmo se interpretara si _b adoptara las distintas posibilidades
existentes (por ejemplo que fuera una secuencia vaca, o un dato de caracteres sin
tipar o un elemento, o una secuencia de cinco nodos, etc.). Este tipo de cuestiones
es bsico que puedan resolverse, debido a la flexibilidad del XML, lo que obliga a que
casos como stos deben quedar definidos a lo largo del proceso de consulta.
Para hacer frente a esta necesidad, en XQuery existe una operacin bsica
llamada e!traccin de tio, cuyo significado es evidente. Este proceso de
extraccin de tipo permite que tengan sentido expresiones como:
153
doc("libros.xml)/bib/libro/autor[apellido=`Stevens]
donde siendo aellido un elemento y `Stevens una cadena, se pueda asumir que
pueden ser iguales. La clave reside en que el operador = extrae el tipo de valor del
elemento, obteniendo que es una cadena, lo que permite a XQuery poderla
comparar con "Stevens y tomar la decisin que corresponda.
En la lnea de lo anterior, adelantemos que XQuery incorpora la funcin dataO@
que extrae directamente el tipo del valor correspondiente; por ejemplo:
data( <e xsi:type="xs:integer>4</e>)
una vez validado hace que se obtenga directamente como resultado el entero 4, sin
tener que preocuparse del tipo de dato concreto.
La extraccin del tipo en su forma ms general se llama atomi7acin definida
como la extraccin da valores tipados en cada secuencia de tems; por ejemplo:
avg( 1, <e>2</e>, <e xsi:type="xs:integer>3</e>)
la atomizacin devuelve un valor tipado, esto es 2, la medida de 1, 2, y 3.
Como resultado de la atomizacin cuando se va a efectuar una comparacin, sta
se acaba haciendo en trminos de valores atmicos, de forma que si un operando es
un nodo, se recurre a la atomizacin para convertirlo en un valor atmico. Ello da
lugar a toda una casustica, frente a la que hay que saber cmo proceder.
Veamos lo que ocurre en el caso del elemento recio, segn el tipado que
incorpore el operador (por simplicidad adelantamos el uso de dos de ellos, de
evidente significado e- y 't):
- Si se carece de tipo, se trata como una cadena y en consecuencia slo puede
compararse con otra cadena. Este sera el caso de la consulta:
for $b in doc("libro.xml)//Libro
where $b/titulo eq "Datos en la Web
return $b/precio
- Si los datos dependen de una DTD, no se pueden usar los tipos simples de los
Esquemas, con lo que recio no tiene tipo. Por ello en la siguiente consulta,
es necesario pasar precio a decimal:
for $b in doc("libro.xml)//Libro
where xs:decimal($b//precio) gt 100.00
154
return $/titulo
- Si quien gobierna los tipos es un Esquema que declara precio para un decimal,
nada de lo anterior es necesario.
Como norma general en XQuery, los datos objetivo de consulta se interpretan como
datos tipados, y se fuerza a la consulta a tenerlos que interpretan antes de
comprarlos, con la nica excepcin de que sean cadenas o que efectivamente
contengan los tipos adecuados.
El hecho de que los Esquemas tengan tipos predefinidos permite usarlos para
escribir (unciones similares a las de los lenguajes de programacin convencionales,
aprovechando las estructuras de XML. Como ejemplo, una funcin que comprueba si
un elemento tiene como padre el nodo documento es:
define (unction is-document-element($e as element()) as xs:boolean
{if (se/.. instance of document-node())
then true()
else false()}
de forma que la expresin $e/.. del documento instancia ser cierto cuando se
evale para este nodo.
A pesar de lo dicho, la posibilidad de trabajar con datos poco tipados en ocasiones
es una ventaja no despreciable que el buen uso de XQuery puede explotar. Como
ejemplo, adelantndonos a secciones siguientes, consideremos el caso de una
funcin que devuelva una secuencia de tems en el orden inverso al existente en el
documento, una situacin en la que parece razonable no se especifique ni el tipo del
parmetro de la funcin, ni el tipo que ser devuelto, ya que es razonable que esta
funcin pueda aplicarse a cualquier secuencia de tems; por ejemplo:
define function reverse($items)
{
let $count := count($items)
for $i in 0 to $count
return $items[$counts - $i]
}
el operador to genera sucesiones de enteros (por ejemplo: la expresin 1to 5
genera la sucesin 1, 2, 3, 4, 5) y al escribir reverse (1 to 5) devuelve la secuencia
5, 4, 3, 2, 1. Al no especificar ningn tipo, ni para los parmetros ni para el
resultado, podra usarse para devolver un a secuencia de cualquier otro tipo da
datos.
155
J#8# Cambiar & reestructurar in(ormacin
En XQuery las consultas combinan informacin de una o ms fuentes por lo que
necesariamente sta debe reestructurarse para obtener el resultado deseado. Para
efectuar estas tareas existen una serie de expresiones, llamadas ALWO0 (de las
iniciales FOR, LET, WHERE, ORDER Y RETURN que se pronuncia como en ingls
"flower) que juegan un papel similar al de las instrucciones SELECT-FROM-WHERE
de SQL al asociar valores para poder obtener resultados.
J#8#1# Cl=usulas ALWO0

Se llama tula a una combinacin de variables asociadas a una expresin FLWOR
formada por las clusulas (or o/y let, seguidas por Phere o/y order y
obligatoriamente por return, ya que invariablemente algo se devuelve como
consecuencia de una consulta; por ejemplo:
for $b in doc("libros.xml)//Libro
where $b/@anyo = "2000
return $b/titulo
devuelve los libros publicados en el ao 2000, asociando la variable $b a cada libro
para crear una serie de tuplas. En este ejemplo Phere comprueba si $b/@anyo es
igual a "2000 de forma que return se evala para cada tupla que satisfaga la
condicin. El resultado que se obtiene es:
<titulo>Datos de la Web</titulo>
Las cl=usulas (or & let
Toda expresin FLWOR incorpora al menos una de estas clusulas, existiendo
distintas combinaciones posibles para ellas. As en:
for $i in (1, 2, 3)
return
<tupla><i>{ $i }</i></tupla>
se crea un elemento tupla donde $i se asocial a (1, 2, 3) para construir una sucesin
de enteros, dando como resultado:
156
<tupla><i>1</i></tupla>
<tupla><i>2</i></tupla>
<tupla><i>3</i></tupla>
En cambio la clusula let asocial una variable al resultado global de una expresin
y si no existen en ella ninguna clusula (or, se crea una sola tupla. Si en el anterior
se usa let en lugar de (or, esto es: let $i :=(1, 2, 3), el resultado es una nica
tupla, donde la variable $i est limitada a la secuencia entera de enteros:
<tupla><i>1 2 3</i></tupla>
Cuando let se usa en combinacin con una o ms clusulas (or, las variables
asociadas a let se aaden a las tuplas generadas por la clusula (or; por ejemplo:
for $i in (1, 2, 3)
let $j :=(1, 2, 3)
return <tupla><i>{ $i }</i><j>{ $j }</j></tupla>
obtiene como resultado:
<tupla><i>1</i><j>1 2 3</j></tupla>
<tupla><i>2</i><j>1 2 3</j></tupla>
<tupla><i>3</i><j>1 2 3</j></tupla>
Aplicando la combinacin de (or and let en nuestro ejemplo:
for $i in doc("libro.xml)//Libro
let $c := $b/autor
return
<Libro>{ $b/titulo, <cuenta>{ count($c) }</cuneta>}</Libro>
obtiene como resultado:
<libro>
<titulo>TCP/IP Ilustrado</titulo>
<cuenta>1</cuenta>
</libro>
<libro>
<titulo>Programacin Avanzada en el entorno UNIX </titulo>
<cuenta>2</cuenta>
</libro>
<libro>
157
<titulo>Datos de la Web</titulo>
<cuenta>3</cuenta>
</libro>
La cl=usula Phere
Esta clusula elimina las tuplas que no satisfacen una determinada condicin, de
forma que return slo se evala para aquellas que la superen. As, la bsqueda de
aquellos libros cuyo precio sea de menos de 50.00 C es:
for $b in doc("libros.xml)//libros
where $b/precio < 50.00
return $b/titulo
dando como resultado:
<titulo>Datos en la Web</titulo>
Aunque su anlogo en SQL WHERE slo comprueba valores similares, esta
restriccin no se da en XQuery, donde la clusula Phere puede contener cualquier
expresin que se evale a un valor booleano. As, para obtener ttulos de libros con
ms de dos autores, se escribe:
for $b in doc("libros.xml)//libro
let $c := $b//autor
where count($c) > 2
return $b/titulo
dando como resultado:
<titulo>Datos en la Web</titulo>
La cl=usula order
Esta clusula ordena las tuplas antes de evaluar return, con el objeto de poder
cambiar el orden del resultado. As, para ordenar alfabticamente los ttulos se
puede escribir:
for $t in doc("libros.xml)//titulo
order by $t
return $t
158
donde (or genera una secuencia de tuplas con un nodo titulo en cada una, y a
continuacin order b& las ordena de acuerdo con el valor de los elementos titulo de
forma que return devuelve los elementos titulo en el orden de las tuplas
ordenadas. El resultado obtenido es:
<titulo>Datos en la Web</titulo>
<titulo>Economa de la Tecnologa y el contenido de la TV digital</titulo>
<titulo>Programacin Avanzada en el entorno UNIX</titulo>
<titulo>TCP/IP Ilustrado</titulo>
Esta clusula permite ordenas de forma ascendente o descendente. La siguiente
consulta devuelve los autores, ordenados en orden inverso a su apellido, con su
nombre de pila incluido en el resultado:
for $a in doc("libros.xml)//autor
order by $a/apellido descending, $a/nombre descending
return $a
el resultado obtenido es:
<autor>
<apellido>Suciu</apellido>
<nombre>Dan</nombre>
</autor>
<autor>
<apellido>Stevens</apellido>
<nombre>W.</nombre>
</autor>
<autor>
<apellido>Stevens</apellido>
<nombre>W.</nombre>
</autor>
<autor>
<apellido>Buneman</apellido>
<nombre>Peter</nombre>
</autor>
<apellido>Abiteboul</apellido>
<nombre>Serge</nombre>
</autor>
La cl=usula return
159
Esta clusula est en toda expresin FLWOR y tambin es comn en los elementos
constructores. As por ejemplo, la siguiente consulta usa un constructor de
elementos que proporciona el precio de los libros:
for $b in doc("libro.xml)//libro
return
<presupuesto>{ $b/titulo, $b/precio }</presupuesto>
el resultado que se obtiene es:
<presupuesto>
<titulo>TCP/IP Ilustrado</titulo>
<precio>65.95</precio>
</presupuesto>
<presupuesto>
<titulo>Programacin Avanzada en el entorno UNIX</titulo>
<precio>65.95</precio>
</presupuesto>
<presupuesto>
<titulo>Dato en la Web</titulo>
<precio>39.95</precio>
</presupuesto>
<presupuesto>
<titulo>Economa de la Tecnologa y el contenido de la TV digital</titulo>
<precio>129.95</precio>
</presupuesto>
Existen una gran variedad de aplicaciones del uso de los constructores de
elementos con una clusula return. Por ejemplo, tarea de insertar un elemento
nombrecomleto que mantenga el nombre y apellido del autor se resuelve con una
consulta que aade un nivel de jerarqua para un nuevo elemento
nombrecomleto:
for $a in doc("libro.xml)//autor
return
<autor>
<nombrecompleto>{ $a/nombre, $a/apellido }</nombre completo>
</autor>
la consulta tiene como resultado (para un solo autor):
<autor>
<nombrecompleto>
<nombre>Serge</nombre>
160
<apellido>Abiteboul</apellidos>
</nombrecompleto>
</autor>
J#8#,# +!resiones condicionales
En XQuery se utilizan expresiones condicionales de la misma forma que en otros
lenguajes, por lo que aparece en XQuery tanto la clusula i( como then y else.
Como ejemplo para obtener el nombre de dos autores de cada libro (incluyendo "et
al si existen ms de dos autores) se escribe la consulta de la forma:
for $b in doc("libro.xml)//libro
return
<libro>
{ $b/titulo }
{for $a at $i in $b/autor
where $i <= 2
return <autor>{string($a/apellido), ", ",
string($a/nombre)}</autor>}
{if (count($b/autor) > 2)
then <autor>et al.</autor>
else ()}
</libro>
donde la secuencia vaca () se usa para especificar que una clusula no devuelve
nada. El resultado que se obtiene es:
<libro>
<titulo>TCP/IP Ilustrado</titulo>
<autor>Stevens, W.</autor>
</libro>
<libro>
<titulo>Programacin Avanzada en el entorno UNIX</titulo>
<autor>Stevens, W.</autor>
</libro>
<libro>
<titulo>Datos en la Web</titulo>
<autor>Abiteboul, Serge</autor>
<autor>Buneman, Peter</autor>
<autor>et al.</autor>
</libro>
<libro>
161
<titulo>Economa de la Tecnologa y el contenido de la TV digital</titulo>
</libro>
J#K# Oerar en X;uer&
Aunque ya han sido utilizadas en algunos casos, veamos de forma ms sinttica las
piezas con las que se elaboran las consultas XQuery.
J#K#1# Cuanti(icadores
Para las consultas basadas e una condicin resulta bsico determinar tanto si existe
al menos un tem que las satisfaga, como saber si todos los tems involucrados en
ella lo hacen; ste es el mbito respectivo de los cuantificadores existencial y
universal. Consideremos la consulta:
for $b in doc("libros.xml)//libro
where some $a in $b/autor
satisfies ($a/apellido="Stevens and $a/nombres="W.)
return $b/titulo
en ella, el cuantificador existencial some incluido en la clusula Phere se encarga
de comprobar si existe al menos un autor que satisfaga las condiciones especificadas
dadas dentro de los parntesis. El resultado obtenido es:
<titulo>TCP/IP Ilustrado</titulo>
<titulo>Programacin Avanzada en el entorno UNIX</titulo>
Por su parte, un cuantificador universal tiene la funcin de comprobar si todos los
nodos de una determinada secuencia satisfacen la condicin objetivo de la consulta.
As, para obtener todos los autores que se llamen W. Stevens, pueden escribirse:
for $b in doc("libro.xml)//libro
where every $a in $b/autor
satisfies ($A/apellido="Stevens and $a/nombre="w.)
return $b/titulo
Obtenindose como resultado:
<titulo>TCP/IP Ilustrado</titulo>
<titulo>Programacin Avanzada en el entorno UNIX</titulo>
<titulo>Economa de la Tecnologa y el contenido de la TV digital</titulo>
162
Es significativo sealar en este ejemplo la aparicin en el resultado del titulo
)conom+a de la tecnolo+a y el contenido de la 8! diital que corresponde a un libro
con editores pero sin autores, lo que significa que en este caso la expresin
_b6autor se ha evaluado sobre una secuencia vaca, obteniendo un resultado que
no debe sorprender, ya que coherentemente con los principios de la lgica formal,
un cuantificador universal aplicado a una secuencia vaca siempre vuelve cierto, y en
consecuencia del citado libro aparece en el resultado de la bsqueda.
J#K#,# Oeradores
En su mayora los operadores que se utilizan en XQuery coinciden con los habituales
en el resto de lenguajes de programacin; los ms utilizados son los siguientes:
Aritm<ticos. +, -, *, div, idiv, mod, todos con su significado convencional.
Comarativos. tambin se corresponde con los operadores con los operadores
habituales conocidos: eq =, ne =, It <, le <=, gt >, ge >=.
Debe sealarse que tanto estos operadores comparativos como los aritmticos,
cuando se enfrentan a secuencias vacas, actan de la misma forma que SQL lo hace
con los "null.
$e osicin. XQuery proporciona dos operadores para determinar la posicin de
los dos nodos en el orden propio de un documento, que son tiles cuando por alguna
razn el orden de los elementos sea significativo. El operador $a <<$b devuelve
cierto si $a precede a $b en el orden del documento y viceversa con $a >>$b.
$e 4ecuencia: estos operadores actan combinando secuencias para obtener
como resultado otra secuencia, sin cambiar el orden interno que stas tenan en el
documento original; son stos: union% intersect% & e!cet.

Los operadores union (que tambin admite la forma lxica: |) e intersect
equivalen a las correspondientes operaciones conjuntistas, aunque ahora con
secuencias de operados. El operador e!cet, parte de dos secuencias de nodos y
devuelve otra con todos los nodos presentes en el primer operando que no figuran
en la segunda.
Debe sealarse que se pueden combinar estos operadores de secuencia, siempre
que se mantenga el principio de que ningn nodo aparezca dos o ms veces. En el
caso de que algn operando involucrado en estas operaciones contenga un tems
que no sea un nodo se declara el error correspondiente.
163
J#K#2# Aunciones rede(inidas

En XQuery existen todo un conjunto de funciones predefinidas muchas de las cuales
son habituales en otros lenguajes y otras estan pensadas especficamente para
procesar XML. Como en SQL son muy usadas funciones como: minO@% ma!O@%
countO@% sumO@% av'O@%etc., cuyo significado, parmetros y resultados son
suficientemente evidentes.
Otras funciones familiares de XQuery son las que operan sobre nmeros:
roundO@% (loorO@ & ceilin', sobre cadenas: concatO@% strin'Rlen'thO@% startsR
PithO@% endeRPithO@% subdtrin'O@% uerRcaseO@% co'erRcaseO@ que incluso
pueden adaptarse para admitir como parmetros distintos tipos de datos simples.
Respecto a las funciones propias de XML que no suelen estar en otros lenguajes,
algunas de ellas ya las hemos definido y utilizado como es el caso del docO@# En este
grupo son especialmente usadas: notO@% emt&O@ & e!istsO@# La primero tiene el
correspondiente significado booleano basado en negacin; emt&O@ es una funcin
que detecta si una secuencia es vaca; la funcin opuesta es e!istsO@, que indica si
una secuencia contiene al menos un tems.
Adems de las citadas, hay que detectar aquellas funciones que acceden a tipos
de informacin de un nodo, como strin'O@ que devuelve el valor de cadena de un
nodo o la ya utilizada dataO@, que devuelve el tipo de valor al nodo. Ms
especficamente, el valor de strin'O@ incluye la representacin del texto encontrado
en el nodo y sus descendientes, concatenndolos segn el orden de aparicin en el
documento; por ejemplo:
string((doc("libros.xml)//autor)[1])
da como resultado la cadena "Stevens W. (cuyo resultado exacto depende de los
espacios en blanco que hubiera en el documento implicado).
Para finalizar, es importante sealar que en XQuery es perfectamente posible
crear funciones definidas por el usuario, construidas sobre la biblioteca bsica que
proporciona el lenguaje. En particular estas funciones definidas por el usuario
permiten abreviar consultas muy largas. Esta posibilidad de recurrir a XQuery desde
otros lenguajes hace que las implementaciones XQuery forme parte de entornos de
programacin basados en Java o C#, o incluso de sistemas de gestin de bases de
datos relacionales, de forma que este entorno proporciona a XQuery tanto funciones
externas como variables.
164
El desarrollo de XQuery es uno de los ms laboriosos, pues depende de mltiples
circunstancias, y debe tener en cuenta una gran cantidad de requisitos. Lo
presentado en este captulo es slo una introduccin a estos puntos, con el objetivo
de poner de manifiesto los problemas a los que se tiene que enfrentar la nueva Web
para alcanzar todas las posibilidades. A lo anterior hay que aadir el propio
problema del desarrollo de Sistemas de Gestin de Base de Datos que manejen
documentos XML, un tema al cual nos referimos brevemente en el ltimo captulo
pero que por el momento no forma parte de la familia XML.
U CAP*TULO
Trans(ormacin de documentos. X4LT

8.1. El problema de presentar un documento XML.
8.2. XSLT: un lenguaje para transformaciones.
8.3. Modelo y Procesado XSLT.
8.4. La recomendacin XSLT.
8.5. Estructura de un documento hoja de estilo XSLT.
8.6. Combinar Hojas de Estilo.

Ha llegado el momento de encarar el hecho de que XML no incorpora ninguna
semntica intrnseca de presentacin, por lo que sin una tecnologa apropiada
ningn procesador sabra cmo representar el contenido de un documento, como no
fuera de una cadena indiferenciada de caracteres. De hecho, cuando XML empez su
camino no exista ningn navegador capaz de mostrar sus documentos como no
fuera en forma de un simple texto, lo que supona un paso hacia atrs respecto a
HTML, que s interpretaba el documento de una pgina Web y lo traduca en texto
y/o imgenes formateadas.
Manejar documentos XML tanto por parte de un humano como por medio de una
aplicacin software conlleva a que difcilmente se podrn usar en la forma en que se
presentan al ser accedidos, y en consecuencia es inevitable someter a estos
documentos a algn tipo de transformacin para que se adapten y sean tiles en
cada contexto concreto.
En el presente captulo se presentan las tcnicas que permiten transformar un
documento XML en otro, de forma que el resultado que se obtenga se adapte a los
distintos usos y necesidades, que puedan ser muy numerosas. Como simple
165
reflexin considrese la siguiente relacin, que no pretende ser exhaustiva, de
posibilidades:
- Pasarlo a HTML para mostrarlo en un determinado tipo de Terminal en la Web.
- Ponerlo en formato MIF (Maker Interchange Format) para posteriores
intercambios.
- Darle un estilo para su presentacin y publicacin impresa.
- Pasarlo a WML para presentarlo sobre perifricos WAP.
- Convertirlo a distintos dialectos XML para la transferencia de datos en B2B.
- Convertirlo a texto plano.
- Etc.
El uso de transformaciones de documentos se da en dos grandes escenarios: en la
conversin de datos entre aplicaciones XML, y en el proceso de presentacin de
documentos XML. En primer caso hay que declarar que, para este intercambio, no es
posible limitarse a la simple transformacin de datos XML, ya que tambin se debe
combinar datos XML con otros que no lo sean, y en consecuencia hay que dotar al
XML de una tecnologa bsica que permita las conversiones correspondientes. El
segundo problema surge de la propia arquitectura de la Web y de los propios
requisitos de XML, lo que supone poder transformarlos datos antes de poder
presentarlos.
U#1# +l roblema de resentar un documento XML
Resolver la presentacin de un documento XML es inevitablemente complejo, no slo
por los temas de formato sino tambin por la necesidad de contar con tcnicas que
hagan de puente con las posibilidades especficas de cada perifrico (impresoras,
pantallas, terminales de voz, etc.) a la hora de que las personas puedan acceder a
los contenidos de los documentos. Esta adaptacin es imprescindible, ya que a modo
de ejemplo hay que estar preparados tanto para que sta pueda ser objeto de
impresin, como de publicacin en la Web, siendo obvio que tanto una como otra
presentan sus particulares caractersticas.
166
Desde los inicios del XML se fue consciente de la necesidad de disponer de
herramientas que ejercieran un control detallado de la presentacin de la Web, y tal
como se adelant en el Captulo 2, se recurri a los CCS como una tecnologa ya
existente que se aplica con xito a los documentos HTML y que se adopt al XML si
grandes dificultades. Aunque las tecnologas de presentacin no forman parte de la
familia XML, al objeto de ubicar este problema para los documentos XML, vamos a
resumir brevemente este tema, sobre el que volveremos en el ltimo captulo.
U#1#1# XML B C44
Recordemos el modelo y la secuencia de pasos que sigue un agente de usuario para
soportar la tarea que desempea el trabajo de los CSS cuando se procede a la
presentacin en un perifrico de un documento HTML:
1. Analizar el documento fuente y crear el rbol de documento.
2. Identificar el tipo de medio seleccionado para la presentacin.
3. Recuperar las hojas de estilo asociadas al documento especificadas para el tipo
de medio seleccionado.
4. Anotar cada elemento del rbol documento asignando un nico valor para cada
propiedad que sea aplicable al tipo de medio usado. Una buena parte de los
clculos de estos valores dependen de los algoritmos de formateo apropiados
para el tipo de medio, as, por ejemplo, si se va a trabajar con una pantalla, el
agente de usuario utiliza el llamado modelo de formato visual.
5. A partir del rbol anotado, generar una estructura de formato, que se parece el
rbol de documento aunque no necesita tener "forma de rbol, ya que la
estructura depende de cada implementacin y puede contener informacin que
la contenida en el rbol del documento; as un elemento que en el documento
tuviera el valor `noneF para la propiedad disla& no generar nada en la
estructura de formato, cuando otros elementos s pueden generar informacin
adicional para esta estructura de formato.
6. Transferir la estructura de formato obtenida al medio seleccionando. As, por
ejemplo, el agente del usuario que utilice una pantalla escoge una anchura
segn las dimensiones de cada Terminal, y en el caso de un perifrico de audio
se determina el espacio de frecuencias, y as para cada medio.
167
Como se observa CSS permite referirse a los siguientes aspectos:
- Elementos del rbol del documento y determinadas relaciones entre ellos.
- Atributos de estos elementos y sus valores correspondientes.
- Algunas partes del contenido del elemento.
- Elementos del rbol que estn en un determinado estado.
- Algunos aspectos del entorno en el que va a presentarse la estructura del
formato del documento.
El uso de CSS en XML es anlogo al que se hace de l en HTML, aunque la forma de
acceder a la hoja de estilo CSS sea distinta, ya que en XML se tiene que hacer por
medio del uso de una IP encargada de proporcionar el proceso necesario para incluir
una hoja de estilo CSS en el documento. Con este uso se lleva ala prctica el
objetivo de poder cambiar las condiciones de la presentacin, sin que el documento
XML sufra ningn cambio.
Vamos a trabajar con un ejemplo tradicional en XML acerca de la participacin de
un determinado artculo:
<ARTICULO>
<TITULO>Federico el grande de encuentra con Bach</TITULO>
<AUTOR>Johann Nikolaus Forkel</AUTOR>
<PARA>
Una tarde, cuando me dispona a usar su
<INSTRUMENTO>flauta</INSTRUMENTO> y sus msicos se preparaban para
ensayar, un criado le anuncio la llegada de un grupo de visitantes
</PARA>
</ARTICULO>
Para presentar este documento de forma inteligible. en primer lugar ah que
declarar y distinguir entre aquellos elementos que se van a presentarse de forma
continua (llamado "inlinelevel) esto es, sin provocar saltos de lnea, y de los que
van a presentarse en bloques distintos, produciendo por tanto un alto de lnea
("block-level). A tenor del texto del documento, a parte del tratamiento que se
decida para los elementos TITULO y AUTOR, las dos primeras instrucciones CSS que
deben darse para darse el texto del artculo son:
INSTRUMENTO { display: inline }
ARTCULO, TITULO, AUTOR, PARA { display: block }
168
declarando que el elemento INSTRUMENTO no cambie de lnea, dando a
continuacin la lista de elementos que deben mostrarse en bloques distintos, de esta
forma las lneas del contexto se muestran con el mismo estilo, y tal como se desea,
la palabra "flauta, al ser objeto de un elemento expreso INSTRUMENTO puede
detectarse debidamente dentro del bloque del prrafo PARA del que forma parte.
Para obtener la presentacin deseada, basta con aadir la IP correspondiente a la
forma:
<?xml-Stylesheet type="text/ccs href="bach.css?>
<ARTICULO>
.
</ARTICULO>
Evidentemente la presentacin puede mejorarse, aadiendo nuevas reglas de
estilo al archivo bach#css para ir detallndola hasta el nivel que se desee. Como
sabr el lector, las posibilidades que se presentan son prcticamente infinitas.
Notemos asimismo, que al igual que ocurre con el elemento HTML st&le, en XML
tambin es posible trabajar apuntando a un elemento del propio documento, esto
es, sin tener que recurrir a un archivo externo, cosa que puede ser interesante si la
hoja de estilo es muy especifica de documento; para ello se usa la misma IP
apuntando ahora a un elemento identificado por un atributo id, en lugar de hacerlo
al archivo externo; por ejemplo:
<?xml-Stylesheet href="#style type="text/css?>
<ARTICULO>
<EXTRAS id="style>
INSTRUMENT { display: inline }
ARTCULO, TITULO, AUTOR, PARA { display: block }
EXTRAS { display: none }
</EXTRAS>
<TITULO> Federico el Grande se encuentra con Bach </TITULO>
.
</ARTICULO>
U#1#,# $el C44 al X4L

A pesar de su buen funcionamiento, hay que recalcar que CSS es incapaz de
ejecutar operaciones lgicas, tales como construcciones "if-then, que muchas veces
son imprescindibles para adaptar un documento de un tipo de presentacin a otra, y
169
desafortunadamente afecta a las posibilidades de poder cambiar de un documento
XML a otro similar. Ante la perspectiva de las nuevas posibilidades de la Web, se
tom conciencia que los CSS podran ser insuficientes para la tarea de adaptacin de
los documentos XML a los distintos perifricos y por ello se siguieron nuevos
desarrollos, impulsados especialmente por la aparicin de los Esquemas y por la
creciente complejidad de las hojas de estilo.
Los objetivos de XML motivaron que W3C impulsara un metalenguaje para
expresar hojas de estilos, lo que dio lugar a XSL (Extensible Stylesheet Language).
La idea consiste en utilizar una clase de documentos XML que definen una hoja de
estilo y que expresan la forma en que un contenido estructurado en un documento
XML puede presentarse en distintos entornos. En otras palabras, una forma de hacer
que el contenido XML pueda asociarse a un estilo, a un diseo y a una paginacin
que generalice lo que CSS consigue en la ventana de un navegador.
Pronto se lleg a la conclusin de que dar estilo a un documento supone dos
etapas, primero transformarlo y despus darle formato. As, cuando W3C elabor el
primer borrador XSL, ste contena una sintaxis que soportaba este doble cometido,
de forma que el lenguaje se poda descomponer en un sublenguaje para transformar
documentos XML y un vocabulario XML y un vocabulario XML para la especificacin
de una semntica para los formatos de presentacin, cosa obviamente bastante
compleja y prolija al tener que soportar presentaciones muy especiales y diversas, y
siempre dependiente de la aparicin de nuevos perifricos de salida. Desde entonces
el concepto que dio lugar al XSL se descompuso en dos vertientes: XSLT (un
lenguaje para transformar) y XSL-FO (un vocabulario XML para dar formato y
presentacin a los documentos al que nos referimos en el ltimo captulo).
Por tanto XSL hay que verlo como un marco en el que:
- Los datos se transforman, filtran y ordenan.
- Las partes de un documento se definen.
- Se da formato a los datos basndose en sus valores (como por ejemplo
mostrar nmeros negativos en rojo, etc.).
- Dar una salida por XML a diferentes medios tales como pantallas, papel, voz,
etc. Por ello y debido a su origen, la aplicacin XML XSL-FO a veces se llama
XSL.
Es interesante profundizar en las razones que condujeron al desarrollo de las
recomendaciones relacionadas con XSL en paralelo con las de CSS. La respuesta se
encuentra en la siguiente tabla:
170
TABLA 8.1. Comparacin entre CCS y XSL
donde se observa que la nica caracterstica en comn en ambos consiste en que
dan estilo a documentos XML y puesto que XSL puede usarse para transformar datos
XML a documentos HTML/CSS en un servidor Web, se comprende que ambos
lenguajes adems de complementarse mutuamente puedan utilizarse en paralelo.
Por ello W3C se asegur de que CSS y XSL trabajaran con el mismo modelo de
formato subyacente, consiguiendo que los diseadores dispusieran bsicamente de
las mismas caractersticas de formato en los dos mecanismos.
Terminemos haciendo notar que el uso de CSS sigue siendo el mtodo ms
familiar para presentar documentos XML en navegadores Web, y aunque no puedan
alterar significativamente los fragmentos de un documento XML ni ejecutar cualquier
lgica basada en los datos, sigue siendo muy til en aquellas que no precisan
transformaciones importantes, como es la presentacin en un navegador Web.
U#,# X4LT. un len'ua3e ara trans(ormaciones#

De la seccin anterior se deduce que, tanto al usar CSS como XML, se trabaja sobre
la base de aceptar dos documentos: uno fuente con datos XML y otro en forma de
hoja de estilo para producir un tercer documento a los efectos de presentacin del
contenido XML. Para abordar la posibilidad de transformar documentos se retom la
visin de XML como una interfaz entre diversos lenguajes de mercado, donde cada
uno esta basado en su propio vocabulario y su propia sintaxis, de forma que una
misma semntica y un mismo contenido para expresarse con sintaxis diferentes. As
surge la idea de expresar la semntica de un determinado documento utilizando una
sintaxis equivalente, en lo que se llama una transformacin.
En el concepto de transformacin se puede reconocer la equivalencia que existe
entre lo9s distintos lenguajes de programacin, en el sentido de que un mismo
algoritmo se expresa de distintas formas para su ejecucin por una misma CPU. As
se pens en la posibilidad de someter a los documentos a una transformacin
plasmada en una hoja de estilo, que fuera la deseada en cada momento.
Al objeto de facilitar, toda esta gama de posibilidades, desde los primeros
desarrollos de XSL, se cuenta con un lenguaje que soporta la ejecucin de toda esta
variedad de transformaciones que se puedan necesitar, se trata del ya citado XSLT
(Extended Stylesheet Language Transformation) definido como un lenguaje XML
basado en reglas que transforman la estructura y contenido de un documento XML
en otro, tambin basado en texto, siguiendo las indicaciones de un segundo
documento llamado transformacin u ho3a de estilo que vara segn sea el
resultado final que se persiga.
171
La procedencia comn del CSS y del XSL explica que en la terminologa XSLT se
hable de hoja de estilo. La evolucin del XML ha demostrado que un lenguaje
dirigido a transformaciones es necesario en muchas tareas, y no exclusivamente en
las relaciones con la presentacin o el estilo, aunque la tarea de especificar el estilo
de un documento siga siendo una de las funciones ms importantes del lenguaje
XSLT dentro de la familia XML.
De forma ms concreta en XML se llama trans(ormacin a un programa que a
partir de un documento fuente XML y de un documento hoja de estilo, lee y cambia
el documento fuente para obtener un documento resultado, siguiendo las reglas
expresadas en el contenido del documento hoja estilo. Tras ser sometido al proceso
de transformacin, el documento resultante puede ser muy distinto de fuente,
incluyendo la posibilidad de aadir texto o etiquetas, aunque siempre obteniendo un
tipo de documento basado en texto. As, mediante una transformacin pueden
obtenerse otros documentos en: HTML, XHTML, SVG, texto plano, etc., e incluso
otro XML.
Por tanto, los procesadores XSLT partiendo de dos documentos, la fuente y la hoja
de estilo, generan un archivo que puede, en principio, tener casi cualquier formato
estructurado basado en texto. Toda transformacin trabaja con dos rboles, el rbol
fuente al cual se le aplica la transformacin y el rbol resultado que adopta la forma
de un rbol de elementos y atributos.
El procesado XSLT puede darse en tres contextos diferentes: a) en un proceso en
"batch, b) sobre un servidor Web y c)en un navegador. En el primer caso, el
procesador parte de archivos (los archivos fuente y las correspondientes hojas de
estilo) y genera otro archivo sobre una determinada carpeta que representa los
resultados de la transformacin. Como el procesado tiene lugar en un servidor Web,
tambin involucra archivos fuentes y hojas de estilo, aunque ahora en lugar de
escribir los archivos resultantes en un disco, los resultados fluyen en el navegador
del usuario. Finalmente, cuando los navegadores soportan el procesado XSLT, tanto
los archivos fuentes como las hojas de estilo se mandan al navegador que presenta
el resultado correspondiente directamente al usuario. Como puede verse, el entorno
de trabajo del XSLT puede ser diverso, aunque su funcionalidad sea la misma en los
tres contextos.
Centrndonos en la Web, la trascendencia e importancia del XSLT reside en la
posibilidad que proporciona que el mismo documento fuente pueda publicarse con
toda libertad, sobre no importa que tipo de perifrico, usando para ello la hoja de
estilo adecuada a cada caso (convirtindolo a HTML en el caso de un sitio Web, a
WML para telefona celular, a VoiceXML para aplicaciones interactivas basadas en
voz, etc.).
172
XSLT, al permitir transformar un XML a otro XML con estructuras diferentes dadas
por distintos Esquemas o DTDs, abre una va para hacer accesible una informacin
que sin la transformacin no sera posible. Considrese el caso de un documento que
obedezca a una DTD propietaria, cuyos detalles pueden mantenerse ocultos, pero
que s permita el intercambio XML con el exterior siempre que se respete una DTD
que sea un estndar industrial. En este caso, el "propietario puede escribir hojas de
estilo XSLT que permitan la "traduccin entre ambas estructuras, puedo mantener
la confidencialidad que le interesa, al tiempo que facilita el acceso a la informacin
que puede ser transparente para el usuario.
U#2# Modelo & Procesado X4LT
En lnea con su condicin de lenguaje declarativo, la hoja de estilo en XSLT incorpora
la descripcin de una serie de reglas que indican cmo deben procesarse cada uno
de los nodos del documento fuente, usando para ello una estructura de objetos
como modelo de datos. Estas reglas son conocidas tambin como atrones o
lantillas (temlate rules) ya que durante la ejecucin tiene lugar una serie
sistemtica de comprobaciones entre partes del documento fuente y estos patrones,
de forma que cuando se produce un ajuste de alguna de ellas, se dispara el
mecanismo, obteniendo el resultado especificado en la regla. Se llama constructor
al programa que despus de evaluar secuencialmente los nodos del documento
fuente obtiene a partir de ellos una parte del rbol resultado, de acuerdo con lo
declarado por las reglas de las hojas de estilo correspondientes.
Como toda regla XSLT stas constan de dos partes: una primera en la que dado
un patrn se buscan los elementos del rbol fuente que se ajustan a l, para lo que
se recurre a expresiones XPath y, una segunda, donde la plantilla construye una
parte del rbol resultado con el constructor. Por ejemplo, si el documento fuere
contienen el fragmento:
<titulo> La historia de IP </titulo>
y la hoja estilo contiene una planilla tal como:
<xsl:template match="titulo>
<H2>
<xsl:template>
</H2>
</xsl:template>
se produce un ajuste con el elemento titulo, dando como resultado la creacin de lo
indicado en el cuerpo del elemento objeto del ajuste, concretamente:
173
<H2> La historia de PI </H2>
Donde la etiqueta <xsl:value-of/> se reemplaza por el valor actual del elemento
titulo% como veremos en su momento.
Es importante destacar que una misma hoja de estilo se puede aplicar a una
amplia gama de documentos que tenga parte de sus estructuras semejantes entre s
y, que por lo tantotas hojas de estilo se construyen con total autonoma del
documento que vana ayudar a transformar.
Cuando se ha adelantado las estructuras de los rboles resultados pueden diferir
sensiblemente de las estructuras de los correspondientes rboles fuentes, ya que
durante el proceso de construccin del rbol resultado, los nodos del rbol fuente
pueden filtrarse, reordenarse e incluso se pueden aadir en el resultado final
cualquier nueva estructura que se desee. Por tanto, los pasos que sigue un
procesador XSLT son:
1. Examinar los documentos fuente y las hojas de estilo.
2. Analizar y comparar los nodos para aplicar las reglas de la hoja de estilo.
3. Crear el rbol resultado.
4. Completar el documento resultante.
Como un primer ejemplo, veamos el paso de un documento de XML a HTML, y para
obviar las consideraciones relacionadas con el formato de presentacin del
resultado, recurriremos a mostrarlo con IE. Trabajamos por una parte, con el
documento fuente intro#!ml#
<?xml version = "1.0?>
<?xml-Stylesheet type = "text/xsl href = "intro.xsl?>
<miMensaje>
<mensaje> Bienvenidos a XSLT</mensaje>
</miMensaje>
donde ya se ha incorporado la instruccin de proceso, que interesa a nuestros
efectos:
<?xml-Stylesheet type = "text/xsl href = "intro.xsl?>
y por otra parte, con la hoja de estilo intro#!sl.
174
<?xml version = "1.0?>
<xsl:Stylesheet version = "1.0?>
xmlns:xsl = "http://www.w3.org/1999/xsl/transform>
<xsl:template match = "miMensaje>
<html>
<body><xsl:value-of select = "mensaje/></body>
</html>
</xsl:template>
</xsl:Stylesheet>
En el documento fuente, con el uso de 4t&lesheet se asigna la hoja de estilo
(intro#!sl) a usar sobre l, donde el atributo t&e define el tipo de archivo (los dos
valores posibles que puede tomar son te!t6!sl, que denota un documento XSL y
te!t6css que denota un documento CSS) y el atributo hre( indica el archivo
correspondiente a la hoja de estilo.
En la hojas de estilo la instruccin <xsl:template match = "miMensaje> muestra
el elemento XSLT temlate, cuyo atributo match especifica los nodos del
documento fuente a utilizar, usando para ello una expresin XPath, que en este caso
simplemente es el elemento miMensa3e. Este elemento dispara el inicio del
documento fuente e forma que lo contenido dentro de l indica la salida que debe
generarse. As, las lneas:
<html>
<body><xsl:value-of select = "mensaje/></body>
</html>
indican la sucesin de elemento HTML y de texto que deben copiarse en la salida.
Puesto que los elementos nodo que se correspondan deben pasar al documento
resultado por la presencia del elemento !sl.valueRo( select, se observa que el
elemento miMensa3e del fuente se corresponde con los contenidos del elemento
temlate, de forma que los contenidos texto correspondientes pasan a formar parte
del rbol resultante. Al someterlos al procesador XSLT, se obtiene lo mostrado en la
FIGURA 8.1., ya expresado usando IE:
FIGURA 8.1.
U#5# L a recomendacin X4LT

Un documento X4LT es un documento XML con el espacio de nombres:
htt.66PPP#P2#or'61MMM6X4L6Trans(orm (para el que suele usarse como
175
prefijo !sl) y cuyo elemento raz es xsl:Stylesheet. El documento puede incluir tanto
elementos no definidos por XSLT, como otros procedentes de otras hojas de estilo
incorporado por inclusin o por importacin. Su sintaxis es la de XML y su
vocabulario consta de etiquetas especiales que presentan operaciones concretas a
realizar con el texto del documento fuente; son muchos los elementos que
constituyen su vocabulario, por lo que no es inmediato usarlo con facilidad, por ello
el lector debe saber que suele costar bastante tiempo llegar a ser competente
transformando documentos.
Ante la inevitable complejidad que encierra este lenguaje, nuestro objetivo se
centra solamente en dar una perspectiva de sus posibilidades. Empecemos citando
los principales puntos referidos al lenguaje XSLT:
1. Como lenguaje XML, est constituido por una larga lista de elementos y a la
hora de definir las hojas de estilo se incorporan todas las posibilidades que
ofertan los Esquemas XML.
2. Cuenta con una serie de recursos para ayudar a comprobar el ajuste o no a los
patrones definidos en las reglas de las hojas de estilo, facilitando por ello que
se dispare la regla que proceda a la transformacin correspondiente.
3. Hay definida una larga lista de funciones que pueden usar en su seno
expresiones XPath, lo que facilita la tarea de bsqueda de determinados nodos
y patrones en el seno del documento a transformar. La relacin entre XPath y
XSLT es tan importante que los documentos XPath 2.0 y XSLT 2.0 se
publicaron conjuntamente en febrero del 2001, de forma que el primero lo
acabaron escribiendo conjuntamente ambos grupos responsables de estos.
Recomendaciones.
4. Al basarse el funcionamiento de XSLT en la combinacin de los dos
documentos, el fuente y la hoja de estilo, es obligado incluir en el primero de
la Instruccin de Proceso que desencadenara el proceso de forma que a partir
de su ejecucin, el procesador XSLT, con la hoja de estilo como base, recorre
el rbol fuente, siguiendo el mtodo de primero en profundidad, para luego
agrupar a los elementos, reordenarlos y finalmente proceder a la copia del
texto de los nodos apropiados en el documento resultado.
5. En todo momento del proceso se tienen controlados los tems siguientes:
- El nodo contexto
- La posicin y tamao del contexto
- Los espacios de nombres que estn en la panormica de la expresin utilizada.
- La biblioteca de funciones disponible.
- El conjunto de variables asociadas al espacio de nombres.
176
U#8# +structura de un documento ho3a de estilo X4LT

En el documento XSLT existen bsicamente dos categoras de elementos: los
llamados elementos de alto nivel encargados de ejecutar una tarea especfica y las
instrucciones de plantilla que definen las condiciones para que se efecte cada
transformacin. Son ejemplos de elementos de alto nivel:
xsl:include que permite referenciar plantillas procedentes de una fuente externa.
xsl:output que proporciona mtodos para la salida (xml, html, text).
xsl:strip-space que elimina antes del procesamiento todos los nodos consistentes
en espacios en blanco.
Respecto a las instrucciones en XSLT, stas se suelen clasificar en cinco
categoras, segn tengan que ver con:
- La obtencin de patrones (instrucciones encargadas de definirlos patrones a
los que deben ajustarse los nodos del documento fuentes para que se activen
las reglas expresadas en la hoja de estilo).
- La manipulacin de datos (indican los cambios a efectuar en los datos, como
consecuencia de ajustarse a una regla).
- El flujo de control (permite utilizar la interaccin y la condicionalidad a la hora
de procesar la hoja de estilo).
- El diseo de documentos (proporciona mecanismos para la construccin del
documento resultado).
- La definicin de tipos de contenidos (permitiendo definir variables, texto o
nmeros).
U#8#1# Obtencin de atrones
Estas instrucciones son la encargadas de describir las reglas que especifican la
transformacin a aplicar a los elementos del documento fuente. Las ms usuales
son:
177
- < xsl:template match=" . "> utilizada para definir las reglas de
transformacin para los nodos que coinciden con la expresin XPath (que se
expresa entre comillas) que viene dada en el atributo match. As, si una hoja
de estilo quiere declarar que cada vez que se encuentre un elemento
`NOMBRE tenga lugar alguna accin, se usa una sintaxis del tipo:
<xsl:template match="NOMBRE>
..
</xsl:template>
- < xsl:apply-templates select=" . "> encargada de aplicar todos los patrones
posibles a los elementos coincidentes con la expresin XPath, que acompaa al
atributo select con la que selecciona los elementos objetivos. En
consecuencia, al&Rtemlates indica al proveedor que debe buscar
cualquier patrn que se pueda activar, situado por debajo del novel del nodo
contexto. Su significado es parecido a "examinar todo lo existente; es un
comando prcticamente en los documentos XSLT.
La combinacin de estas dos instrucciones es clave para el procesamiento XSLT, ya
que previamente a cualquier transformacin, la parte del documento fuente XML que
contiene la informacin que va a pasar al documento resultado debe ser copiada y
por ello sta debe seleccionarse con una expresin XPath. Por ello a la seccin del
documento seleccionada por match se llama genricamente un nodo XSLT y en el
caso de que lo que vaya a seleccionarse sea un documento completo, el nodo es su
raz, para lo que se usa de acuerdo co XPath: matchCD6E. As al escribir:
<xsl:template match="/>
<xsl:apply-templates/>
</xsl:template>
donde la barra, /, indica al procesador que este nodo se aplica al nivel de la raz de
documento, pensando en la raz como si fuera un par imaginario de tarjetas que
incluyeran a la totalidad del documento.
U#8#,# Maniulacin de datos
El objetivo de estas instrucciones consiste en extraer datos de los nodos fuente para
poder procesarlos antes de incluirlos en el documento resultado. Como ejemplo de la
funcionalidad de este grupo de instrucciones, digamos que en XSLT, en vez de
proporcionar un patrn para cada elemento de un documento acta proporcionando
un elemento que duplica los nodos desde el rbol fuente al rbol resultado. Por ello
hay que prestar especial atencin al elemento <xsl:copy> que adems de producir
178
una copia del nodo contexto, lo ubica en el rbol resultado. As tomando como
fuente intro#!ml ya visto y la hoja de estilo siguiente:
<?xml version = "1.0?>
<xsl:Stylesheet version = "1.0
xmlns = "http://www.w3.org/1999/xsl/transform>
<xsl:template match = "miMensaje>
<xsl:copy>
<xsl:apply-templates/>
</xsl:copy>
</xsl:template>
<xsl:template match = "mensaje>
<xsl:copy>
&apos;Hola mundo&apos; para variar
</xsl:copy>
</xsl:template>
</xsl:Stylesheet>

se observa que gracias a las instrucciones:
<xsl:copy>
<xsl:apply-templates/>
</xsl:copy>
se produce un duplicado del nodo contexto en el rbol resultado y el aparece
adems:
<xsl:copy> &apos;Hola mundo&apos; para variar </xsl:copy>
el elemento co&, reemplaza el contenido del elemento con texto.
El resultado de la transformacin de intro#!ml es:
<?xml version = "1.0?>
<miMensaje>
<mensaje>`Hola mundo para variar </mensaje>
</miMensaje>
Obviamente lo ms habitual es la copia de un subrbol, a partir de un nodo
determinado especficamente para ello. En este caso se usa:
<xsl.copy-of select="..>
179
que devuelve el conjunto correspondientes a la expresin XPath indicada en el
atributo select que duplica en el resultado los nodos seleccionados.
Al contrario del elemento co&, el elemento co&Ro( duplica tanto todos los hijos
(texto, instrucciones de procesamiento, comentarios, etc.) como los atributos del
nodo.
Otras instrucciones de manipulacin de uso frecuente son:
- <xsl:value-of select="..> que devuelve bien el valor del atributo indicado,
bien el texto asociado con el nodo proporcionando (ntese que los atributos
deben ir precedidos de @).
- <xsl:sort..> indica los criterios de ordenacin para el conjunto de nodos que
se est procesando mediante otras instrucciones.
U#8#2# Las instrucciones de (lu3o de control

Ya hemos adelantado que la ventaja ms importante que explicaba la aparicin del
XSL frente a los CCS estriba en la posibilidad de efectuar operaciones de control
sobre el documento. Por ello interesan especialmente aquellas instrucciones XSLT
que representan procedimientos que actan bien como interacciones, bien como
condicionales. Veamos cmo se pueden utilizar estos dos mecanismos de
programacin, en el seno de una hoja de estilo.
*terando en X4LT
Consideremos a modo de ejemplo ms significativo, la instruccin:
<xsl:for-each select="..>
cuyo significado es aplicar las reglas que constituyen el cuerpo de la instruccin, a
cada uno de los elementos que coinciden con la expresin XPath que acompaa a
select. En otra palabras la expresin (orReach es un bucle que procesa todos los
nodos que estan en select.
As, si !sl.(orReach se usa con la expresin XPath `GENTE/PERSONA se
procesara todos los elementos `PERSONA presentes en el elemento contexto
`GENTE (en particular si el nodo GENTE fuera el nodo raz se incluiran todos los
elementos `PERSONA). En el caso de que ste (orReach apareciera seguido de:
180
<xsl:value-of select="NOMBRE/>,
el resultado sera que, una vez !sl.(orReach hubiera seleccionado un elemento
`NOMBRE.
XSLT permite iterar a travs de un conjunto de nodos de forma que los nodos
tambin pueden ordenarse, si ello fuera necesario. Partamos del documento fuente
uso#!ml:

<?xml version = "1.0?>
<?xml:Stylesheet type = "text/xsl href = "uso.xml?>
<libro isbn = "999-99999-9-x>
<titulo> El primer libro de XML </titulo>
<autor>
<nombre>Isabel </nombre>
<apellido>Martn</apellido>
</autor>
<captulos>
<preface num = "1 paginas = "2>Bienvenidos</preface>
<capitulo num = "1 paginas = "4>XML f&#225;cil</capitulo>
<capitulo num = "2 paginas = "2>Elementos XML</capitulo>
<apndice num = "1 paginas = "9>Entidades</apndice>
</capitulo>
</libro>
Apliquemos la hoja de estilo uso#!sd, donde se usa la iteracin, para lo que
contiene un fragmento de la forma:
<xsl:for-each select = "capitulos/preface>
<xsl:sort select = "@num order = "ascending/>
<tr>
<td align = "right>
preface <xsl:value-of select = "@num/>
</td>
<td>
<xsl:value-of select = ". /> (
<xsl:value-of select = "@paginas/> paginas )
</td>
</tr>
</xsl:for-each>
<xsl:for-each select = "capitulos/capitulos>
.##
</xsl:for-each>
<xsl:for-each select = "capitulos/apendice>
181
.##
</xsl:for-each>
Las sentencias del tipo: <xsl:for-each select = "capitulos/.>se aplica al
contenido de cada uno de los nodos seleccionados por el atributo select, y la lnea
<xsl:sort select = "@num order = "ascending/> muestra el elemento XSLT sort,
que ordena los nodos seleccionados por el elemento (orReach por el contenido del
campo del atributo order (en este caso se ordenan ascendentemente por el atributo
num).
A continuacin se construye como salida HTML, una fila de una tabla que muestra
el nmero, el ttulo y el Nmero de pginas para cada elemento re(ace% caitulo &
aendice. El resultado final en IE es el mostrado en la FIGURA 8.2.
FIGURA 8.2.
+!resiones condicionales
XSLT tambin proporciona elementos para realizar procesamiento condicional, tal
como hace una sentencia if en programacin tradicional. As: <xsl:if test=".##>
permite escribir una reglas que aplicar un determinado patrn slo si la expresin se
evala como cierta. Otras expresiones condicionales son: xsl:choose, xsl:when, y
xsl:otherwise.

Sea un documento fuente a'enda#!ml, desde el que se quiere organizar citas y
tareas conociendo fecha, hora y tipo de tarea.
<?xml version = "1.0?>
<agenda>
<anyo value = "2000>
<fecha mes = "7 dia = "15>
<nota hora = "1430>Visita al m&#233;dico</nota>
<nota hora = "1620>Clase de f&#237;sica en la BH291C</nota>
</fecha>
<fecha mes = "7 dia = "4>
..
<fecha mes = "7 dia = "20>
...
<fecha mes = "7 dia = "20>
..
<fecha mes = "7 dia = "20>
..
</anyo>
182
</agenda>
La siguiente hoja de estilo, lo visualiza en un documento HTML.
<xsl:choose>
<xsl:when test = "@hora &gt;= `0500 and @hora &gt; `1200>
Ma&#241;ana (>xsl:value-of select = "@hora/>):
</xsl:when>
<xsl:when test ="@hora &gt;= `1200 and @time &lt; `1700>
Tarde (<xsl:value-of select = "@hora/>):
</xsl:when>
<xsl:when test = "@hora &gt;= `1700 and @hora &lt;= `2359>
Tarde-Noche (<xsl:value-of select = "@hora/>):
</xsl:when>
<xsl:when test = "@hora &gt;= `0100 and @hora &lt; `0500>
Noche (<xsl:value-of select = "@hora/>):
</xsl:when>
<xsl:otherwise>
Todo el d&#237;a.
</xsl:otherwise>
</xsl:choose>
<xsl:value-of select = ". "/>
<xsl:if test = ". = ` ` "> n/a </xsl:if>
Las sentencias !sl.Phen testCS\hora[S, muestran en Phen (cuando)
condicional, donde el atributo test proporciona la condicin que debe ser
comprobada, de forma que Phen termina cuando se ha obtenido el primer resultado
dado como verdadero. Como el uso de este elemento condicional comprobamos si el
atributo hora del elemento nota tiene un valor mayor que L8LL y menor que
1,LL.
Por su parte, en: <xsl:otherwise> Todo el d&#237;a. <7xsl:otherwise> se
muestra la condicin otherPise del elemento choose que debe ejecutarse en caso
de no haber encontrado ningn acierto con ninguna sentencia Phen#
Las lneas <xsl:if test = ". = ` ` ">n/a </xsl:if>muestra la sentencia condicional i(
que al contrario que el elemento choose proporciona un test condicional simple.
El resultado expresado en IE se muestra en la Figura 8.3.
FIGURA 8.3.
183
U#8#5# Las instrucciones de diseNo
Estas instrucciones permiten la creacin en el documento resultado de nuevos
elementos y atributos, as como instrucciones de proceso y comentarios. Para
facilitar esta tarea de diseo, la recomendacin XSLT define planillas por defecto, de
forma que el fragmento:
<xsl:template match = "/ *|>
<xsl:apply-templates/>
</xsl:template>
hace una correspondencia entre el elemento raz del documento (/) y cualquier nodo
elemento (*) de un documento, aplicando las plantillas a sus nodos hijos.
Resulta fcil de comprobar que:
<xsl:template match = "test() | @*>
<xsl:value-of select = ". "/>
</xsl:template>
obtiene la correspondencia para nodos texto (te!t()) o nodos atributos (@) danto
como salida sus valores respectivos.
Asimismo para los nombres de lo elementos y atributos existen las sentencias:
<xsl:element name = "...> y <xsl:attribute name = "..>
Mientras que por su parte:
<xsl:template match = "processing-instruction() | comment()/>
realiza la correspondencia entre nodos de instrucciones de proceso y nodos
comentarios aunque no efecta ninguna sobre ello.
Sea el documento fuente XML deortes#!ml que califica varios deportes:
<xml version = 1.0.?"
<deportes>
<juego titulo = "baloncesto> <id>234</id>
<para> <ms popular en algunos Pases </para>
</juego>
<juego titulo = "baseball> <id>431</id>
<para> El ms conocido en Amrica </para>
</juego>
184
<juego titulo = "ftbol> <id>123</id>
<para> El deporte ms conocido en todo el mundo </para>
</juego>
</deportes >
y tratemos de convertirlo en un documento co nuevos elementos y atributos como:
<?xml version = "1.0 encoding = UTF-8?>
<deportes>
<baloncesto id ="243>
<comentario> Ms popular en algunos Estados. </comentario>
</baloncesto>
<baseball id=431>
<comentario> El ms conocido en Amrica. </comentario>
</baseball>
<ftbol id="123>
<comentario> El deporte ms conocido en todo el mundo </comentario>
</futbol>
</deportes>
Para ello hay que definir la hoja de estilo:
<?xml version = "1.0?>
<xsl:Stylesheet version = "1.0
xmlns:xsl = "http://www.w3.org/1999/XSL/transform>
<xsl:template match = "/ ">
<xsl:apply-templates/>
</xsl:template>
<xsl:template match = "deportes>
<deportes>
<xsl:apply-templates/>
</deportes>
</xsl:template>
<xsl:template match = "juego>
<xsl:element name = "{@titulo}>
<xsl:attribute name = "id>
<xsl:value-of select = "id/>
</xsl:attribute>
<comentario>
<xsl:value-of select = "para/>
</comentario>
<xsl:element>
</xsl:template>
185
comprobndose que efectivamente transforma el documento XML fuente en el
documento XML deseado.
U#8#8# $e(inicin de tios#
En XSLT existen una serie de elementos encargados de definir tipos de contenidos
tales como: variables de vnculos de datos (xsl:variables), texto normal (xsl:text) o
nmeros (xsl:number). La consecuencia ms importante es que ello permite a XSLT
poder usar variables para procesar la informacin, contando para ello con el
elemento variable. As, dado el documento fuente uso#!ml, consideremos la
siguiente hoja de estilo:
<?xml version = "1.0?>
<xsl:stylesheet version = "1.0
xmlns:xsl = "http://www.w3.org/1999/XSL/transform>
<xsl:template match = "/ ">
<total>
Numero de paginas =
<xsl:variable name = "suma
select = "sum(libro/capitulo/*/@paginas)*/>
</total>
</xsl:template>
</xsl:Stylesheet>
donde en:
<xsl:variable name = "suma select = "sum(libro/capitulo/*/@paginas)/>
se crea un elemento variable con el atributo suma (que guardar la suma del
nmero de pginas del libro) y el atributo select con el valor
sumOlibro6caitulo6`6\a'inas@% una expresin XPath que suma los nmeros
de los atributos ='inas de los elementos caitulo. A continuacin en <xsl:value -
of select = "$suma/> el elemento valueRo( da como salida la variables suma
utilizando el signo dlar ($) para referenciar a la variable.
El documento resultado en IE se muestra e la figura 8.4.
FIGURA 8.4.
donde la expresin XPath ha calculado la suma del nmero de pginas en los
elementos re(ace, cada caitulo y de aendice que es 17.
186
U#K# Combinar ho3a de estilo

XSLT facilita la modularidad a la hora de manejar sus hojas de estilo. lo que permite
tanto importar como incluir, en un documento XSLT. La diferencia entre estos dos
elementos con capacidad de combinacin, include e imort, reside en que las
plantillas incorporadas por medio del elemento include tienen la misma prioridad
que las plantillas locales, en cuyo caso si una platilla se duplicara la que acta es la
ltima utilizada.
Sobre el ya visto documento fuente uso#!ml. veamos un ejemplo de cmo trabaja
include para incorporar otros documentos XSLT en un documento XSLT. Sea la hoja
de estilo:
<?xml version = "1.0?>
<xsl:Stylesheet version = "1.0
xmlns:xsl = "http://www.w3.org/1999/xsl/transform>
<xsl:template match = "/ ">
<html>
<body>
<xsl:apply-template select = "libro/>
</body>
</html>
</xsl:template>
<xsl:template match = "libro>
<H2>
<xsl:value.of select = "titulo/>
</H2>
<xsl:apply-templates/>
</xsl:template>
<xsl:include href = "autor.xsl/>
<xsl:include href = "capitulos.xsl/>
<xsl:template match = "*|text()/>
</xsl:Stylesheet>
donde <xsl:include href = "autor.xsl/> <xsl:include href = "capitulos.xsl/>
muestra la inclusin de los archivos referenciados por el atributo hre(.
A continuacin se muestran los documentos XSLT, autor#!sl y caitulos#!sl que
tiene el objetivo de representar el nombre del autor y los nombres de los capitulos
conjuntamente. Son stos respectivamente:
<?xml version = "1.0?>
187
<xsl:Stylesheet version = "1.0
xmlns:xsl = "http://www.w3.org/1999/xsl/transform>
<xsl:template match = "Autor>
<p>Autor:
<xsl:value-of select = "nombre/>,
<xsl:value-of select = "apellido/>
</p>
</xsl:template>
</xsl:Stylesheet>
<?xml version = "1.0?>
<xsl:Stylesheet version = "1.0
xmlns:xsl = "http://www.w3.org/1999/xsl/transform>
<xsl:template match = "capitulos>
Capitulos:
<ul> <xsl:apply-templates select = "capitulo/> </ul>
</xsl:template>
<xsl:template match = "capitulo>
<li> <xsl:value-of select = ". "/> </li>
</xsl:template>
</xsl:Stylesheet>
De forma que al aplicar la primera hoja de estilo al documento fuente uso#!ml da
como resultado, expresado en IE, que muestra la Figura 8.5.
FIGURA 8.5.

M CAPTULO
*nteraccin & mane3o de documentos XML. $OM
188
9.1. Manejo de documentos XML con una aplicacin.
9.2. La Arquitectura DOM.
9.3. Interface DOM.
9.4. Trabajar con DOM.
9.5. SAX y su arquitectura.
Como ltimo miembro de la familia XML, en este captulo nos planteamos la
tecnologa por la cual una aplicacin externa, escrita en no importa qu lenguaje de
programacin, puede manejar un documento XML. Ello supone estandarizar las
formas de interaccionar de un documento XML con otras piezas de software, al
objeto de poder llevar a cabo determinadas tareas imprescindibles en el procesado
de datos, y sin cuya garanta e compatibilidad y accesibilidad, no llegarn a
satisfacerse los objetivos que se persiguen con XML.
M#1# Mane3o de documentos XML con una alicacin#
La arquitectura bsica que gobierna la interaccin, en ambos sentidos, entre la
aplicacin entre una aplicacin externa y un documento XML se muestra en la Figura
9.1. en la que entre una y otro aparecen una serie de elementos software, que so
objeto de presente captulo.
FIGURA 9.1. Relaciones entre aplicacin y documentos.
Como se observa, en el proceso de proporcionar a la aplicacin datos procedentes
de documentos XML, el primer paso para que stos sean accesibles es el anlisis del
propio documento, con el consiguiente proceso de descomposicin de nodos y piezas
identificables (etiquetas, trozos de texto, IP, comentarios, etc.) de tal manera que
una vez hecho, se puedan integrar con la aplicacin correspondiente, mediante una
API (Application Programming Interface) debidamente estandarizada.
Respecto al problema inverso, esto es, que la aplicacin pueda generar
documentos XML en su nivel ms bsico, siempre se puede pensar que la aplicacin
se puede obtener como resultado directo un marcado XML, generando el
correspondiente flujo de caracteres que produzca un documento. Sin embargo,
aunque ello no sea difcil, si es evidentemente muy laborioso al tener que respetar
todas y cada una de las reglas sintcticas del XML.
Lo anterior conduce a que muy a menudo sea ms fcil para aplicacin
descomponer el proceso de obtencin del documento en dos fases, la primera
consistente en construir, mediante una API, una estructura de datos en forma de
189
rbol que describa el documento a generar para a continuacin en la segunda fase
poner en marcha un proceso que obtenga el marcado XML buscado. Como se
observa, mediante APIs se enfrenta dos problemas en principios distintos: por un
lado escribir un documento XML (serializacin) y por otro analizar los documentos.
Al estar ambos procesos obviamente orientados a la sintaxis, se fuerza a la
aplicacin a trabajar teniendo en cuenta conceptos tales como elementos, atributo,
segmentos de texto, etc., cosas en principio alejadas de la preocupacin del autor de
la aplicacin, lo que proporciona una inestimable ayuda a la hora de enfrentarse con
documentos XML.
Todo ello hace necesario que la interaccin aplicacin/documento quede lo ms
encapsulada posible y en consecuencia que incorpore los mayores niveles posibles
de estandarizacin. En la prctica, las aplicaciones suelen trabajar con una visin
poco detallada, adoptando una aproximacin de alto nivel respecto a sus datos, de
tal forma que tratan de abstraerse de los detalles sintcticos, limitndose a exponer
el significado y la semntica de los datos manejados. En otras palabras, las
aplicaciones interaccionan habitualmente con APIs orientadas a datos, por lo que se
acaba introduciendo una capa de abstraccin de datos entre las APIs orientadas a
resolver los problemas de sintaxis XML y la lgica propia de la aplicacin. Esta
descomposicin se trata de esquematizar con la Figura 9.2. donde se traduce el
hecho de que el autor de cada aplicacin trate de trabajar al nivel lo ms alejado
posible de las peculiaridades propias de los documentos XML, siempre con el
esquema mostrado en la anterior Figura 9.1.
FIGURA 9.2. Accin de las APIs sobre la Aplicacin
M#1#1# /eneracin de documentos. 4eriali7acin
En resumen, aunque, como se ha dicho, siempre una aplicacin puede escribir
directamente un marcado XML generando a partir del correspondiente flujo de
caracteres, cosa laboriosa al tener que respetar las reglas sintcticas, algunas de
ellas objeto de un particular cuidado: citacin de atributos, supresin de caracteres,
etc., las aplicaciones se limitan a construir una estructura de datos en forma de
rbol que describa el documento a generar, de tal manera que posteriormente un
mdulo distinto e independiente de la aplicacin pueda recorrerlo para obtener el
marcado correspondiente de sus elementos.
El proceso anterior, conocido genricamente en Informtica como seriali4acin,
consiste en convertir los datos de la aplicacin a un tipo de datos expresados
secuencialmente, como es el caso de documentos XML, de forma que el resultado
sea una representacin de los primeros, en nuestro caso representados con sintaxis
190
XML. El proceso inverso, consistente en generar datos para la aplicacin a partir de
documentos XML, recibe el nombre de deseriali4acin.
Para el caso de XML, existen distintas tecnologas construidas especficamente
para serializar y deserializar datos, basadas en estructuras de datos propias de los
Esquemas que incorporan mdulos generadores de cdigo. Este proceso de
resumen en la Figura 9.3.
FIGURA 9.3. Proceso de serializacin y deserializacin en XML.
Como puede observarse en la Figura 9.3. que resume el proceso habitualmente
utilizando, para llevarse a la prctica, basta con invocar al compilador de esquemas
(sean DTDs o Esquemas XML) y a partir de l, la aplicacin puede interaccionar
utilizando los mdulos generadores de cdigo (en ambos sentidos entre aplicacin y
documentos) para serializar y deserializar, de igual forma que lo hace cualquiera
otra API.
M#1#,# Tios de AP*s entre documentos & alicaciones
Para enlazar el resultado de anlisis de documentos con el posterior proceso de sus
datos existen dos posibilidades:
a) Aprovechar la estructura de rbol con la que el analizador lo representa en
memoria para las posibles modificaciones del mismo (aadir, borrar nodos,
etc.) de forma parecida a como trabaja una Base de Datos, aunque ahora
usando esta estructura de rbol.
b) Asumir que a medida que el documento se analiza, se generan una serie de
notificaciones, llamadas eventos, lo que permite tomar decisiones ante cada
uno de ellos.
En la primera posibilidad se basa la idea que produce la Recomendacin W3C, DOM
(Document Object Model), mientras que la segunda es la utilizada por SAX (Simple
API for XML), desarrollado en 1998, de manera independiente al W3C. Aunque tanto
DOM como SAX sean dos APIs que acceden a la informacin contenida en un
documento XML, se observa lo que hacen de forma sensiblemente distinta. Por su
lado, DOM se basa en una jerarqua de nodos en rbol con todos los datos del
documento ubicados en memoria, cosa que permite acceder a ellos de forma
inmediata, pudiendo, en consecuencia, aadir y borrar nodos, lo que supone tener
la capacidad de modificar el documento de forma realmente sencilla antes de pasarlo
a la aplicacin. Mientras, por su parte SAX, en lugar de trabajar con la estructura
global del rbol, se limita a detectar eventos, y a partir de ello invocar mtodos, de
191
forma que los datos se pasan a la aplicacin tal como la APIs los va encontrando en
el documento, con ello se evita tener que disponer de la totalidad del rbol en
memoria, bien es cierto que a costa de no cambiar realmente el documento original.
Como puede verse, a la hora de elegir entre una u otra posibilidad, existe una
negociacin que implica a parmetros tales como las necesidades de memoria, le
eficiencia computacional y las facilidades de programacin. Se observa que SAX es
ms eficiente y ocupa menos memoria, mientras que DOM permite recorrer y
manipular el documento con ms facilidad; consecuencia de ello es que SAX se use
normalmente para leer documentos que no tienen que ser modificador mientras que
DOM se reserva para situaciones ms complejas, aunque el soporte que DOM tiene
por parte de la W3C, y las crecientes posibilidades de los equipos de computacin
hagan que este sea cada vez ms usado como puente entre las aplicaciones y los
documentos XML que aquellas utilicen.
En cualquier caso es importante recalcar que ambas APIs juegan el papel de
interfaz independiente del lenguaje y de la plataforma, permitiendo que programas y
"scripts accedan, analicen y actualicen dinmicamente el contenido, estructura, y
estilo de un documento; gracias a ello, tras el proceso, los resultados
correspondientes pueden reincorporarse a la pgina de procedencia.
En el mundo Java se usa API estandarizada llamada Dava A@I for ;M2 @roccessin
3DA;@6 que adems de instanciar los analizadores XML, analiza documentos usados
SAX o DOM. Ntese que de hacho (y esto vale para el resto de lenguajes de
programacin), si no se contara con JAXP, las aplicaciones Java no seran
completamente portables a los distintos analizadores XML, porque cada uno de ellos,
siguiendo SAX o DOM, tendran diferentes APIs para crear, configurar u procesar
documentos.
M#,# La Ar-uitectura $OM
Como sabemos, el objetivo de DOM es facilitar la obtencin de programas que
proceden documentos XML utilizando una serie de interfaces independientes, de
forma que si se cambia de lenguaje no sea necesario cambiar el modelo de
programacin e interaccin. En consecuencia, todos los analizadores disponen de
una biblioteca de programas (API DOM) para navegar, leer, crear, presentar, y
editar datos XML, que aprovechen las posibilidades que ofrece la representacin
especifica del documento en el llamado r*ol 7GM, que explicaremos a continuacin.
Con DOM se pretende escribir programas que creen y manipulen documentos y
para ello se recurre a utilizar interfaces que los hagan independientes del navegador,
del servidor y de la plataforma, de forma que pueda conseguirse que al cambiar el
192
lenguaje en la aplicacin usada, no sea necesario cambiar el modelo de
programacin usando. Ello explica la existencia de analizadores DOM para los
distintos lenguajes de programacin, y posibilita la actuacin de las interfaces DOM,
que detallaremos ms adelante. En conclusin, los interfaces DOM describen una
sintaxis de bajo para construir documentos XML que conllevan la importante
propiedad de poder interaccionar, sin ningn problema, con el lenguaje de
programacin que se use en cada momento.
M#,#1# +volucin de $OM

DOM empez siendo una mera interfaz para que los navegadores pudieran
identificar y manipular los elementos de una pgina Web (es el llamado DOM Nivel
0)creando para ello un documento organizado jerrquicamente constituido por
nodos. Ms adelante, en 1998, apareci DOM Nivel 1 que ya incorporaba un API con
todas las interfaces para los diferentes tipos de informacin que pueden encontrarse
en un documento XML, incluyendo los mtodos y propiedades necesarias para
trabajar con estos objetos. Este Nivel 1 incluye soporte para XML 1.0 y HTML (vase
FIGURA 9.4.) donde cada elemento est representado como una interfaz,
independiente del lenguaje y de la plataforma, lo que permite a los programas
acceder dinmicamente a los documentos. En resumen, el DOM Nivel 1 estandariza
el marco para el uso de documentos dinmicos en la Web.
FIGURA 9.4. Arquitectura DOM Nivel 1.
DOM Nivel 2 extendi el Nivel 1, al permitir detectar y usar la informacin de los
espacios de nombres que fuera aplicable para un nodo. Adems, aadi nuevos
mdulos que soportan CSS y eventos, as como mtodos para la manipulacin de
rboles (rango de rboles y mecanismos). Completando en el ao 2000, se puede
esquematizar de la forma que muestra la Figura 9.5.
FIGURA 9.5. Arquitectura DOM Nivel 2.
En el Nivel 3, objeto de Recomendaciones W3C durante 2004, incorpora una
interfaz definida en IDL (Interfaz Description Language) de CORBA, as como
interfaces para Java y JavaScript. Asimismo, incluye un mejor soporte para crear
documentos, refuerza el soporte para los espacios de nombres, y aade nuevos
mdulos para trabajar con la familia XML, entre los que cabe destacar: cargar, y
salvar documentos, validar las expresiones XPath, seleccionar nodos utilizados en
XSLT, extender los eventos del interfaz de usuario. La Figura 9.6. muestra un
resumen de la arquitectura de DOM Nivel 3.
FIGURA 9.6. Arquitectura DOM Nivel 3.
193
M#,#,# La estructura de =rbol en $OM
Al ser el objetivo de DOM hacer de puente entre una aplicacin y un documento,
para poder trabajar, DOM crea un rbol exterior al documento, para cuya
construccin hay que decidir los tipos de nodo a utilizar y sus ubicaciones en
determinadas categoras. Tanto para introducir y presentar la estructura de un rbol
DOM, como para los ejemplos que siguen a lo largo del resto del presente captulo,
consideremos el documento edidos#!ml:
<?xml version="1.0 encoding="UTF-8?>
<!DOCTYPE PEDIDO SYSTEM "pedidos.dtd>
<pedidos>
<pedidos>
<idcliente limite="1000>12341</idcliente>
<estado>pendiente</estado>
<tem enstock="S itemid="SA15>
<nombre>Silln plata</nombre>
<precio>825.00</precio>
<cantidad>1</cantidad>
</tem>
<item enstock="N itemid="C49>
<nombre>Cama Madera </nombre>
<precio>49.00</precio>
<cantidad>1</cantidad>
</tem>
</pedido>
<pedido>
<idcliente limite="150> 251222</idcliente>
<estado>pendiente</estado>
<item enstock="S itemid="WB78>
<nombre>Manta Invierno </nombre>
<precio>20</precio>
<cantidad>10</cantidad>
</tem>
</pedido>
</pedido>
Para el que se podra pensar en una jerarqua, parecida a:
FIGURA 9.7. Propuesta de rbol para pedido.xml.
194
A pesar de la aparente coherencia de este rbol, hay que hacer notar que en esta
estructura slo estn representados en nodos de elementos, cuando stos no son el
nico tipo de nodo posible. En efecto, aunque un nodo elemento es un contenedor
de informacin, donde puede haber otros nodos (nodos texto, nodos atributos, etc.)
se tiende a olvidar que existe la posibilidad de un contenido mixto, puestos que
existen nodos hijo que contienen estos que son simples caracteres (un espacio en
blanco, por ejemplo) que no son elementos hijo; en consecuencia para nuestra
misin los nodos elementos no son la nica clase de nodo que deben representarse.
Por tanto una representacin ms exacta de edidos#!ml puede verse en la Figura
9.8.
FIGURA 9.8. Mejora de la representacin en rbol de pedidos.xml.
En la nueva figura aparecen dos tipos de nodos: rectngulos y valos que se
corresponden respectivamente con los nodos elementos y con los nodos texto.
Ntese que del elemento edidos cuelgan cinco elementos: dos elementos edidos
y tres nodos texto; por su parte el elemento )tem tiene siete hijos: nombre%
recio% cantidad y cuatro nodos texto.
Con la perspectiva del anterior ejemplo, se pueden deducir que en un rbol DOM
los tipos de nodos que pueden aparecer son muy diversos, concretamente:
- Elementos.
- Atributos.
- Texto (que pueden consistir en informacin o simplemente de espacios en
blanco)
- Documento (el nodo documento es el padre del resto de nodos del documento)
- CDATA.
- Comentarios.
- Instrucciones de Proceso.
- Entidades.
- Nodos de referencia a entidades
- Notaciones
- E incluso fragmentos de documentos
La generalidad que incorpora el rbol DOM es tal, que aunque para el documento
XML debe tener un nico elemento raz a veces en el proceso DOM se crean
estructuras temporales, que incluso llegan a no cumplir con este requisito propio de
los documentos bien formados.
M#2# *nter(aces $OM
195
La interface DOM describen una sintaxis de bajo nivel dirigida a la construccin y
manejo de documentos XML que se puede usar a travs de cualquier lenguaje de
programacin. Al tener como objetivo poder interactuar con los distintos nodos del
rbol DOM, estas interfaces carecen de una implementacin particular, ya que se
especifican en IDL con lo que todo lenguaje puede definir enlaces para ellas. En una
primera aproximacin basta con entender el papel que juegan estas interfaces
dentro de la metodologa seguida por DOM, por ello la primera evidencia es que su
relacin debe coincidir bsicamente con los tipos de nodos que admite un rbol
DOM. As las interfaces ms importantes son:
TABLA 9.1. Interfaces DOM.
El contenido de $OM*mlementation consiste en conseguir la mejor
organizacin posible del rbol DOM para el posterior uso de la informacin incluida
en el documento. Al contrario del resto de interfaces, sus mtodos afectan al
documento como un todo, de forma que , a partir de los diferentes tipos de
informacin que contenga el documento, esta interfaz define los tipos de nodos,
adaptndose a lo permitido por la naturaleza modular de DOM.
El interfaz $ocument representa el nodo del nivel superior del documento
pudindose manejar con mtodos como: Create+lement% CreateAttribute%
/et$ocument+lement% aendChild% /etChild1odes, etc., cuya funcionalidades
respectivas se deducen fcilmente. Entre las mltiples operaciones propias de esta
interfaz se pueden citar: crear nodos, reunir estos nodos en el rbol, localizar los
elementos por nombre sin importar su localizacin, etc.
El interfaz 1ode representa un nodo en un documento DOM, estamos entre sus
principales mtodos, /et1ode1ame% /et1odeT&e% 0elaceChild, etc. Los tipos
de 1ode cubren elementos cuya sintaxis XML es "constante, como es el caso de:
document% element% attributes% charecter data% te!t node% comment%
Proccessin' instruction% que pueden obtenerse a travs del citado mtodo
/et1odeT&e#
El interfaz +lement representa un nodo elemento cuyos mtodos ms
importantes estn relacionados con las funcionalidades propias de un elemento XML,
entre las que puede citarse: /etAttribute (devuelve el valor de un atributo),
/etTa'1ame (devuelve un nombre del elemento), 0emoveAttribute (retira un
atributo del elemento), 4etAttribute (establece un valor del atributo), etc.
El resto de interfaces que figuran en la Tabla son ms simples y sus respectivas
representaciones son fcilmente comprensibles.
M#5# Traba3ar con $OM
196

Esta seccin tiene como nico objetivo introducir someramente las posibilidades que
ofrece DOM y para ello nos vamos a centrar en las operaciones ms bsicas que se
suelen dar entre una aplicacin y un documento; utilizando para ello ejemplos y
situaciones especialmente simples y que un programador experimentando estar en
condiciones de superar utilizando los lenguajes que domine.
Aunque DOM se puede utilizar para cualquier lenguaje, por razones obvias nos
vamos a centrar en Java para introducir su forma de trabajar. En este sentido debe
saberse que la comunidad Java trabajar sobre JDOM un mdulo de JAXP, que como
se ha dicho proporciona una herramienta de alto nivel para poder trabajar con XML.
Para presentar los ejemplos, recurriremos a una serie de pa(uetes bsicos (que
incluiremos con el correspondiente imort) y que en estos momentos agrupan a
una serie de archivos entre s, y de los cuales interesan especialmente:
- or'#P2c#dom (la interfaz API de DOM para programar).
- 3ava#!ml#arser (con las clases para compilar).
M#5#1# Obtencin de un =rbol $OM
La primera operacin, previa a la utilizacin de cualquier interfaz, consistente en
acceder a la informacin de un archivo XML, y ello supone inicialmente analizarlo,
para a continuacin crear un objeto, que a lo largo de lo que sigue llamaremos
$ocument, sobre el cual poder efectuar los procesos propios de DOM. Este objetivo
ser la representacin interna en memoria del documento XML completo.
Esta primera operacin, en el entorno Java, se conoce como el roceso de 2
escalones, ya que se descompone en tres etapas:
1. Determinar un analizador mediante la clase $ocument:uilderAactor&, que es
la encargada de generar un objetivo apropiado para el analizador XML que se
tenga configurado.
2. Crear el llamado $ocument:uilder que proporciona una interfaz estndar
para un analizador XML, que actuar para crear el objetivo $ocument.
3. Analizar el archivo XML y a partir de l, crear $ocument que deber estar de
acuerdo con la especificacin DOM.
Estos pasos se visualizan de la siguiente forma:
FIGURA 9.9. Esquema del proceso de 3 escalones
197
Para llevar a cabo lo anterior, se empieza usando la clase
3ava!#!ml#arsers#$ocument:uilderAactor&, con la que se obtiene la instancia
objeto $ocument:uilder y a partir de ella se crea $ocument, cuyo valor concreto
vendr determinado por la implementacin que produce el constructor usado.
Obsrvese cmo con este proceso JAXP permite que las diferentes aplicaciones
pueden trabajar con distintos analizadores DOM, y aunque el proceso pueda variar
de una implementacin a otra, la tarea es estndar. Por ello a la hora de escribir el
cdigo correspondiente, lo anteriormente expuesto, impone empezar con:
import javax.xml.DocumentBuilder;
import javax.xml.DocumentBuilderFactory;
import java.io.File;
import org.w3c.dom.document;
DocumentBuilder constructorDocumento=
documentBuilderFactory.newDocumentBuilder();
Supongamos que se maneja por un lado el documento adido#!ml, y por otro
una aplicacin llamada ProcesadorPedidos, cuyos objetivos pueden ser todos
aquellos que puedan ser tiles para una empresa. Para empezar a trabajar debemos
escribir:
public class ProcesadorPedidos {
public static void main (string args[]) {
File docArchivo = new File("pedidos.xml);
Document doc = null;
try {
DocumentBuilderFactory dbf = DocumentBuilderFactiry.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
doc = db.parse(docArchivo);
} catch (Exception e) {
System.out.print("Problema analizando el archive: "+e.getMessage()); }
...
De forma que despus de importar las clases necesarias y de crear la clase
correspondiente a la aplicacin ProcesadorPedidos, $ocument:uilder analiza el
archivo para crear $ocument con la ventaja aadida que adems valida el
documento. As para analizar el documento basta con escribir un fragmento que
incluya:
.
try {
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setValidating(true);
198
DocumentBuilder db = dbf.newDocumentBuilder();
doc = db.parse(docArchivo);
}
.
M#5#,# 0ecorrer el =rbol
Una vez creado $ocument debe ser capaz de examinar sus datos, recorriendo su
estructura al objeto de poder revisar, encontrar y mostrar, en su caso, la
informacin que contiene. Para ello hay que navegar a travs de l como una
operacin previa a cualquier procesamiento que se quiera hacer sobre l. Los pasos
para ello son:
a@ Locali7ar la ra)7: ello significa utilizar $ocument+lement, que es la
forma por la cual se designa el elemento raz en la jerga de DOM. Para
ello escribiramos:
import org.w3c.dom.Element:
public class ProcesadorPedidos {
...
System.exit(1);
}
Element raiz = doc.getDocumentElement();
System.out.println("El elemento raz es: " + raz.getNodeName());
...
}
}
...
Obteniendo como resultado:
+l elemento ra)7 es. edidos
b@ 1odos hi3o: a continuacin se debe obtener los nodos hijos, para lo que
puede recurrir a 1odeList que posee por un lado la propiedad de dar la
cantidad de nodos y por otro cuenta con un mtodo que devuelve el nodo
que ocupa la posicin especificada en la lista de nodos a travs de la cual
se itera. El listado que sigue corresponde a una aplicacin que localiza los
nodos hijo y verifica el contenido mostrando el nmero de elementos que
aparecen en el 1odeList resultante#
import org.w3c.dom.NodeList;
199
...
NodeList hijos = raiz.getChildNode();
System.out.println("Hay "+hijos.getLength()
+ nodos en este documento.);
...
Con ello se va obteniendo sucesivamente:
+l elemento ra)7 es. edidos
"a& 8 nodos en este documento
En este apartado de nodos hijos existen otros procedimientos
complementarios y alternativos para poder iterar a lo largo de todos lo
hijos de un nodo; uno de ellos lo ofrece el uso de las relaciones "padre-
hijo y "hermano, que incluso pueden ser ms apropiadas en algunas
situaciones, como la que se da cuando las relaciones mutuas y el orden
en que aparezcan estos hijos sea importante para poder entender los
datos correspondientes.
A tales efectos, si aadimos un bucle "for que empiece con el primer hijo
de la raz, la aplicacin iterar a travs de cada uno de los hermanos de
este primer hijo hasta que todos han sido evaluados. Para conseguirlo se
recurre a la utilizacin de 'etAirstChildO@ y 'et1e!t4iblin'O@ cuya
interpretacin es inmediata.
Gracias a ello, cada vez que la aplicacin ejecute el bucle, encontrar un
objetivo 1ode y podr mostrar su nombre y valor. Concretamente ntese
que los cinco hijos de edido#!ml incluyen los elementos edido y tres
nodos de texto, y que los elementos tienen un valor de "null en lugar del
texto esperado, de forma que los nodos de texto, que son hijos de los
elementos, tienen como valor sus propios contenidos. Por tanto si
escribimos:
...
import org.w3c.dom.Node;
for (Node hijo = raiz.getFirstChild();
hijo != null;
hijo = hijo.getNextSibling())
{
System.out.println(comienzo.getNodeName()+ =
}
...
el resultado que se obtiene es:
200
+l elemento ra)7 es. Pedidos
"a& 8 nodos en este documento
>te!to C
edido C null
>te!to C
Pedido C null
>te!to C
c@ $escendientes: para la obtencin de todos los hijos del nodo raz y no
slo de los de primer nivel, se usa un mtodo recursivo a partir del
elemento raz. As para poder presentar en pantalla el nombre y valor de
todos los elementos, al objetivo de examinar todos los hijos y nietos, se
escribe:
.
public class ProcesarPedidos{
private static void pasarAtraves (Node comienzo)
{
System.out.println(comienzo.getNodeName()+ =
"+comienzo.getNodeValue());
for (Node hijo = start.getFirstChild();
hijo != null;
hijo = hijo.getNextSibling())
{
pasarAtraves(hijo);
}
}
public static void main (string args[]) {
File docArchivo = new File("pedidos.xml);
.
System.out.println("Hay "+hijos.getLength()
+ nodos en este documento.);
pasarAtraves(hijo);
}
}
Obtenindose como resultado:
Pedido C null
>te!to C
edido C null
>te!to C
idcliente C null
201
>te!to C 1,251
>te!to C
estado C null
>te!to C endiente
>te!to C
)tem C null
>te!to C
nombre C null
>te!to C 4illn Plata
>te!to C
recio C null
>te!to C U,8#LL
>te!to C
cantidad C null
>te!to C 1
>te!to C
>te!to C
)tem C null
>te!to C
. y as sucesivamente
d@ Tratamiento de los atributos: con lo visto hasta ahora, se ha indicado
la forma de recorrer la mayor parte de tipos de nodos, sin embargo ello
no es vlido para los atributos que, como se sabe, no son nodos hijos de
ningn nodo. Para afrontar esta tarea, primeramente es necesario
comprobar la salida de cada nodo, al objetivo de comprobar si es o no un
elementos pues, como ya se adelant en su momento, en el rbol DOM
hay que asumir la existencia tanto de +L+M+1TW1O$+ como de
ATT0*:UT+W1O$+, de forma que se tiene un elemento slo en el caso
que 1odeT&e coincida con +L+M+1TW1O$+#

A continuacin, y para cada elemento encontrado, la aplicacin crea
NamedNodeMap cuya funcionalidad es almacenar todos los atributos del
elemento correspondiente.
Supongamos que iteramos a lo largo de 1amed1odeMa para imprimir
el
nombre y el valor de cada atributo de la forma que lo hicimos con
1odeList, con la diferencia de que en vez de estar referenciados por
orden,
ahora lo estn por nombre. Para ello debemos escribir:
.
202
import org.w3c.dom.NamedNodeMap;
.
private static void pasarAtrevesTodo (Node comienzo)
{
System.out.println(comienzo.getNodeName()+ =
"+comienzo.getNodeValue());
if (comienzo.getNodeType() == comienzo.ELEMENT_NODE)
{
NamedNodeMap comienzoAtr = comienzo.getAtributes();
for (int i = 0;
i < comienzoAtr.getLength();
i++) {
Node atr = comienzoAtr.item(i);
System.out.println(" Atributo: "+ atr.getNodeName()
+ = "+atr.getNodeValue());
}
}
for (Node hijo = start.getFirstChild();
hijo != null;
hijo = hijo.getNextSibling())
{
pasarAtraves(hijo);
}
Siendo el resultado que se obtiene:
idcliente C null
Atributo. limite C 1LLL
>te!to C
estado C null
>te!to C endiente
>te!to C
item C null
Atributo. enstoc9 C s
Atributo. itemid C W:JU
>te!to C
[[[
Aunque por razones de brevedad no se desarrolle en esta visin general del proceso
de atravesar un rbol DOM, es importante recalcar que una tarea crucial para
cualquier aplicacin que trabaje con documentos XML es poder manipular los datos,
y ello bsicamente se basa en cuatro operaciones que afortunadamente DOM
soporta sin problema. Debe quedar claro que utilizando DOM se pueda hacer las
operaciones siguientes:
203
- Cambiar el valor de un nodo.
- Aadir nodos
- Suprimir un nodo.
- Reemplazar un nodo.
Los detalles correspondientes para llevar a cabo estas operaciones estn disponibles
en cualquier texto que profundice en las particularidades de DOM, aunque en una
primera aproximacin, como es la del presente texto, sea suficiente como saber que
ello es posible con el uso de DOM.
M#5#2# Obtencin de un documento
A lo largo de 9.4.1. y de 9.4.2. se ha indicado, bien es cierto que de forma muy
esquemtica, el procesado y la manipulacin de datos XML, a traves de DOM, ahora
para completar el ciclo queda por introducir el proceso que permita a la aplicacin
obtener una salida XML, una vez que se sabe cmo procesar un documento XML.
Siguiendo con el ejemplo basado en edidos#!ml, el objetivo que ahora nos
proponemos consiste en obtener un archivo XML que proporcione una relacin de
pedidos, indicando si el nuevo pedido ha sido rechazado o procesado, en funcin de
si la cantidad total de los pedidos de cada cliente haya superado o no el lmite de
crdito decidido por la empresa para cada cliente haya superado o no el lmite de
crdito decidido por la empresa para cada cliente; para ello necesitaremos tener una
indicacin de cada cliente, a travs del idcliente respectivo.
El documento resultado, que queremos obtener para cerrar el ciclo de DOM, lo
llamaremos Pedidosrocesados#!ml y queremos que sea de la forma:
<?xml version="1.0 encoding="UTF-8?>
<PedidosProcesados>
<pedido>
<estado>PROCESADO</estado>
<idcliente>2341</idcliente>
<cantidad>874.00</cantidad>
</pedido>
<pedido>
<estado>RECHAZADO</estado>
<idcliente>251222</idcliente>
<cantidad>200.00</cantidad>
</pedido>
</PedidosProcesados>
204
Sin llegar a entrar en lo detalles propios de la estricta serializacin, vamos a
centrarnos en las fases que ms directamente son funciones que dependen de las
capacidades de DOM, concretamente:
- La preparacin de los datos para poder llegar a obtener un documento XML.
- Los pasos que lleven a la creacin de un archivo XML.
a@ Prearando datos. Resulta obvio que para obtener una salida XML, el primer
paso consiste en que la aplicacin cree un objetivo que pueda ser considerado
como un documento. En consecuencia vamos a aprovechar todo lo que hemos
visto y por conveniencia usaremos el mismo $ocument:uilder que cre
$ocument originalmente. En este caso estamos frente a un problema con
requisitos mucho ms definidos, pues la estructura y contenido de
Pedidosrocesados#!ml nos especifica el tipo de procesado a que hemos de
someter a edidos#!ml, para conseguir el resultado deseado.

Inevitablemente el listado Java correspondiente para ello es extenso que el
que se acompaa, aunque se espera que ste sea entendido sin demasiada
dificultad por el lector que debe centrarse en las operaciones que involucran
las
funcionalidades de DOM. Podemos escribir:
public static void main (string args[]) {
File docFile = new File("pedidos.xml);
Documento doc = null;
Document nuevodoc = null;
try {
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
doc = db.parse(docArchivo);
nuevodoc = db.newDocument();
}
....
Element nuevaRaz = nuevodoc.createElement("PedidosProcesados);
NodeList PedidosProcesados = doc.getElementsByTagName("pedidos);
for (int numPedido = 0;
numPedido < PedidosProcesados.getLength();
numPedido ++) {
Element estePedido = (Element)PedidosProcados.item(numPedido),
Element idcliente =
(Element)estePedido.getElementsByTagName("idcliente).tem(0);
...
Element nuevoPedido = nuevodoc.createElement("pedido);
205
Element nuevoEstado = nuevodoc.createElement("estado);
if (totalDbl > limiteDbl) {
nuevoEstado.appenChild(nuevodoc.createTextNode("RECHAZADO));
} else {
nuevoEstado.appendChild(nuevodoc.createTextNode("procesado));
}
....
Element nuevoCliente = nuevodoc.createElement("idcliente);
Element nuevoTotal = nuevodoc.createElement("total);
nuevoTotal.appendChild(nuevodoc.createTextNode(total));
nuevoPedido.appendChild(nuevoEstado);
nuevoPedido.appendChild(nuevoCliente);
nuevoPedido.appendChild(nuevoTotal);
nuevoRaz.appendChild(nuevoPedido);
}
nuevodoc.appendChild(nuevaRaz);
System.out.print(nuevaRaz.toString());

Se observa que tras procesar edidos#!ml la aplicacin crea un nuevo
elemento
PedidosProcesados que eventualmente ser la raz del nuevo document,
para
a continuacin recorrer todos y cada uno de los pedidos que extraer la i
informacin correspondiente al total de los pedidos de cada cliente, con el
objetivo de poderla comparar despus con la informacin relativa al lmite de
crdito que cada uno tiene asignado por la empresa.
A continuacin, el programa crea nuevos elementos para cada pedido,
concretamente: edido% estado% idcliente% & total#
El siguiente paso consiste en decidir el valor de estado, comprobando si el
total
excede o no al lmite de crdito permitido para cada cliente.

Una vez la aplicacin ha creado los elementos, debe juntarlos, por lo que en
primer lugar se aade la informacin de los elementos estado% cliente & total
al elemento edido que una vez construido se aade al elemento nueva0a)7.
Ntese que mientras se sta haciendo esta tarea, realmente este elemento no
se
ha asociado todava a ningn nodo padre, ya que solamente cuando la
aplicacin
ha completado el proceso, el elemento nueva0a)7 se asocia al nuevo
documento.
206
Finalmente para poder mostrar los datos, nueva0a)7 se convierte a una
cadena
y se manda a System.out. Tras lo cual, dejando a aparte determinados
detalles
que haran innecesariamente largo el cdigo correspondiente, el resultado que
se
obtiene puede expresarse por la secuencia:
<PedidosProcesados><pedido><estado>PROCESADO</estado><idcliente
>12341
</idcliente><total>825.00</total></pedido><pedido><estado><estado>
RECHAZADO</estado><idcliente>251222<idcliente><total>200.0</total>
</pedido></PedidosProcesados>
b@ Creando un archivo XML. Una vez la aplicacin ha creado la informacin
necesaria a partir de edidos#!ml, mandarla a un nuevo archivo es directo ya
que obedece a la misma lgica que mostrarla en una pantalla.

Una de las funcionalidades de DOM consiste en su capacidad para que los
documentos XML puedan crearse de una forma automtica a partir del paso
anterior, cuando se han preparado los datos correspondientes para ello. En
consecuencia debe saberse que usando DOM existe la posibilidad de programar
adecuadamente su serializacin, cosa que viene facilitada por el hecho de que
los datos XML sean slo texto, con lo que se tiene una gran libertad a la hora
de asignarles un formato. A modo de ejemplo con steThrou'hAllO@ se puede
crear un formato que ya incorpore sangrado, lo que en la prctica supone crear
nodos (texto) extra con espacios en blanco.
Para terminar el trabajo que nos habamos propuesto se podra escribir:
..
import java.io.FileWriter;
.
try
{
File nuevoArchivo = nuevoAtchivo("PedidosProcesados.xml);
FileWriter nuevoArchivoFlujo = new FileWriter(nuevoArchivo);
nuevoArchivoFlujo.Write("<?xml version=\.1.0\?>);
nuevoArchivoFlujo.Write("<!DOCTYPE+doc.getDoctype().getName()+ ");
if (doc.getDoctype().getSystemId() !=null)
{
nuevoArchivoFlujo.Write(" System );
nuevoArchivoFlujo.Write(doc.getDoctype().getSystemId());
}
207
if (doc.getDoctype().getPublicId() != null)
{
nuevoArchivoFlujo.Write(" PUBLI );
nuevoArchivoFlujo.Write("doc.getDoctype().get.PublicId());
}
nuevoArchivoFlujo.write(">);
nuevoArchivoFlujo.write(nuevaRaz.toString());
nuevoArchivoFlujo.close();
}
catch (IOExpretion e)
{
System.out.println("No puedo escribir en el nuevo archivo.);
}
...
que acabar produciendo el documento que se desea obtener.
Con lo demostrado a lo largo del ejemplo visto, correspondiente a un
documento
sencillo, se puede suponer que utilizar las posibilidades que ofrece DOM para
este ltimo paso, consistente en obtener un documento XML, es un proceso
simple. Sin embargo en la prctica existen muchos factores que complican esta
tarea, como es la aparicin de archivos contenidos venga afectado por una
DTD
o por un Esquema XML.
Como consecuencia de estas dificultades, en muchos casos resulta aconsejable
optar por la opcin de que sea la propia aplicacin la que se encargue de
efectuar esta ltima funcin. Sin embargo ello no debe ocultar el hecho de que
DOM, con su acta diseo, est en condiciones de resolver todos los pasos que
involucran el uso por parte de una aplicacin de un documento XML, tal como
hemos planteado al iniciar el presente captulo y por ello DOM es una parte
especialmente importante de las tecnologas que forma la familia XML.
M#8# 4AX u su ar-uitectura
Al objetivo de completar el panorama de las APIs actualmente disponibles para
interactuar con documentos XML, vamos a resumir las caractersticas de SAX.
Como se adelant SAX define un modelo basados en eventos, que trabaja
invocando las respuestas de las interfaces a medida que van apareciendo estos
eventos durante el proceso de anlisis del documento. Debido a la propia
simplicidad del modelo, el analizador no necesita guardar en memoria informacin
208
de estado y ello explica que los analizadores SAX sean rpidos y eficaces dentro
del marco de sus posibilidades. Para ver su funcionamiento, consideremos el
documento:
<?xml version="1.0 encoding="UTF-8?>
<Docmuestra>
<saludo>Hola muchachos!</saludos>
</Docmuestra>
frente al que el analizador responde a los siguientes eventos:
- Inicio (del documento)
- Elemento inicial: Docmuestra.
- Inicio del elemento: saludo.
- Caracteres: Hola muchachos!
- Fin del elemento: saludo.
- Elemento final: Docmuestra
- Fin (del documento)
La forma de trabajar de SAX se basa en levantar una bandera (fla) cada vez que se
produce el inicio del evento, bajndola al producirse su finalizacin. A modo de
ejemplo, esto es lo que ocurre para que la aplicacin reconozca que la cadena "Hola
muchachos! se asocia con el elemento saludo.
En la prctica, las situaciones son ms complejas que la que acabamos de citar,
por lo que normalmente se hace necesario mantener una pila con lo elementos que
son objeto de proceso en cada momento. Esta pila, a lo largo de los distintos
eventos que se produce en el ejemplo que usamos, sera:
Inicio ()
Elemento inicial: Docmuestra (Docmuestra)
Inicio del element: saludo (Docmuestra, saludo)
Caracteres: Hola muchachos! (Docmuestra, saludo)
Fin de element: saludo (Docmuestra, saludo)
Elemento final: Docmuestra (Docmuestra)
Fin de documento ()
Esquematicemos finalmente la arquitectura bsica de las APIs de JAXP, cuyos
principales mdulos se muestran en la Figura 9.10:
Como se observa, inicialmente se crea una instancia del analizador SAX a partir de
la "fabrica (4AXParserAactor&) con lo que quien desarrolle utilizando JAXP no
tiene que trabajar directamente con los lectores SAX. Gracias a ello basta con
invocar el mtodo arseO@ del analizador, para que los lectores SAX empiece a
209
disparar eventos hacia la aplicacin y, en su caso, incorpore las respuestas que
reciba en el documento que se est construyendo.
FIGURA 9.10. Esquema del funcionamiento de SAS.
Terminemos indicando que trabajar con SAX en JAXP supone habitualmente usar
cuatro paquetes Java:
TABLA 9.2. Mdulos de software usados con SAX.
El contenido y particularidades de cada uno de estos paquetes obviamente
superan la ptica del presente texto.

1L CAPTULO

Persectiva de las alicaciones XML
210
10.1. Aplicaciones XML
10.2. Vocabularios para aplicaciones XML horizontales
10.3. Aplicaciones de XML en diferentes dominios del conocimiento
10.4. Entornos de Programacin y XML.
Tras los captulos anteriores, el lector no tendr dificultades en aceptar que en un
sentido laxo, la familia XML constituye en su conjunto, y de forma simultnea, un
lenguaje de programacin, un protocolo para la transparencia de datos, y una base
para el manejo de documentos, de forma que a partir de ella se confirma que
esencialmente se cuenta con una herramienta para crear lenguajes y vocabularios
que describan estructuras y datos en cualquier tarea campo o rea de actividad que
se necesiten (grficos, frmulas matemticas, aplicaciones financieras, etc.). Gracias
a ello, en estos momentos, para cada uno de estos usos o funcionalidades, hay
especificados una gran cantidad de sublenguajes XML, a los cuales trataremos de
referirnos dentro de su diversidad, de la forma ms ordenada y sistemtica posible.
1L#1# Alicaciones XML
Como es conocido, una aplicacin ;M2 es una clase de documento XML que se define
utilizando una especificacin o conjunto de reglas adicionales a las propias de la
familia XML (ejemplo de ellas, en forma de recomendaciones y lenguajes, han sido
citadas a lo largo del texto como XHTML o XSL-FO). Al ser necesario distinguir entre
una aplicacin XML y las piezas de software que de algn modo procesan
documentos XML, siempre que se pueda, a estas aplicaciones XML se las conoce
como voca*ularios ;M2 ya que efectivamente se trata de lenguajes cuya sintaxis y
reglas se gobiernan con el uso de la familia XML, produciendo siempre documentos
bien formados y, en la mayora de los casos, adems vlidos.
Por tanto, las aplicaciones XML se caracterizan por el uso de XML, bien para crear
nuevos vocabularios con una semntica dirigida a una funcin concreta (por
ejemplo vocabularios que definen las etiquetas permitidas para describir grficos en
la Web, como en el lenguaje SVG) bien para definir nuevos vocabularios para definir
dominios o rea de conocimiento (frmulas matemticas, aplicaciones financieras,
etc.).
Debido a lo fcil que resulta la creacin de estos lenguajes, se ha creado un
fenmeno Torre de Babel, que el W3C y otras instituciones asumen y tratan de
controlar. Por ello, dentro del universo de siglas existentes en las aplicaciones XML
hay que distinguir, por un lado, los llamamos vocabularios de alicaciones
211
hori7ontales (situados por encima de la familia XML en la figura del Captulo 1)
que proporciona mecanismos, siempre basados en la familia XML, para resolver
tareas genricas como son la interaccin, la presentacin, la seguridad, etc., y por
otro lado, los vocabularios o alicaciones de dominio, donde cada sector de
actividad define sus correspondientes vocabularios con los elementos propios de su
especialidad y campo especfico de aplicacin. Ambos tipos de vocabularios se han
desarrollado para facilitar la interaccin, tanto entre datos y personas, como entre
datos y maquinas.
Como tendremos ocasin de ver las pginas que siguen, cada aplicacin tiene su
vocabulario concreto, dirigido a tareas o servicios determinados y especficos como
son la creacin de documentos de texto (XHTML, MathML), infografa y multimedia
(SVG, SMIL), interaccin vocal (VoiceXML), formularios interactivos (XForms), etc.
La mayor parte de estos vocabularios son aplicaciones ya maduras con muchas
herramientas e implementaciones de uso constante a lo largo y ancho de la Web, lo
que no obsta para que se produzcan sucesivas versiones que tienden a potenciar sus
respectivas posibilidades, frente a las nuevas necesidades que se detectan al usarse
de forma cada dia ms amplia.
1L#,# Yocabularios ara alicaciones XML hori7ontales
Vamos a referirnos a las distintas tareas horizontales que en la Figura del Captulo 1
aparecen sobre la familia XML y que permiten abordar cada una de las tareas
concretas necesarias para el desarrollo de la nueva Web. En lo que sigue vamos a
citar los vocabularios y aplicaciones ms utilizadas, a sabiendas de que la relacin no
va a ser completa, y que en un futuro no lejano estas aplicaciones tendern a
implementarse a medida que aparezcan nuevas necesidades, como consecuencia del
desarrollo de la Web y sus posibilidades.
En este grupo aparecen una serie de vocabularios que estn es constante
evolucin y que el lector no debe tratar de abarcar en su totalidad, pues el universo
XML es muy extenso y no tiene sentido tratar de dominar todos sus aspectos.
Pinsese por ejemplo que puede haber profesionales muy interesados en la
presentacin grfica de documentos, mientras que otro deben preocuparse por los
aspectos de seguridad de estos mismos documentos. Es evidente que cada uno
debe desarrollar su propia especialidad y basta con saber de la existencia de
distintos vocabulario para cada una de estas aplicaciones y ser consientes de que se
dispone de excelentes herramientas para aprender unos y otros, mientras se
dominen las tecnologas bsicas del XML, constituidas por la familia XML.
212
En consecuencia lo que sigue es poco ms que una simple relacin de estos
vocabularios, cuya existencia sin embargo no puede desconocerse. Vamos a
agruparlos en funcin del tipo de problema que abordan.
1L#,#1# Alicaciones ara la resentacin e interaccin de documentos
Este es un apartado especialmente prolijo, por lo que en absoluto puede ser
exhaustivo. Vamos a referirnos sucintamente a los lenguajes de presentacin e
interaccin ms usados en la actualidad y que a grandes rasgos son:
X"TML. Un lenguaje que permite presentar un documento escrito con sintaxis XML
como si fuera un documento HTML. Ello supone que al trabajar con l se tenga que
ser mucho ms escrito que con HTML y as por ejemplo, al incluir una etiqueta de
prrafo resulta obligatorio incluir la etiqueta de cierre, cosa que est permitido en
HTML. XHTML es uno de los vocabularios con mayor impacto, pues bsicamente es
HTML escrito para cumplir con las reglas de un documento XML bien formado. Su
razn de ser escriba en permitir a las aplicaciones XML leer y procesar los
documentos HTML como si fueran documentos XML, ya que aquellos incumplen un
nmero excesivo de reglas propias de XML y ello hace difcil su uso. Adems, la
estandarizacin de una versin HTML basada en XML permite a los navegadores
soportar ambas clases de documentos con la ventaja que XHTML en apariencia no
aparece nada diferente al popular HTML.
X4LRAO. Ya nos referimos a l en el Captulo 8, como la evolucin del XSL para
permitir la inclusin de diversos formatos de salida, dando lugar a la diferenciacin
de una semntica de formato para diferentes tipos de objetos. As XSL-FO como
vocabulario de presentacin permite, tras la correspondiente transformacin a
travs de XSLT, describir la forma como va a ser presentado un documento, sea por
pantalla, papel o cualquier otro medio. As, en el caso de hacerlo en una impresora,
XSO-FO define cosas que son importantes para los documentos impresos con el nivel
de calidad de la impresin, con informacin acerca del tamao de la pgina de papel
(A3, A4, etc.), mrgenes, fuentes de letras, partes a destacar, etc.
4Y/ O4calable Yector /rahics@. Las pginas Web son una combinacin de texto
y grficos y la combinacin de formatos mixtos siempre ha sido problemtica. A
modo de ejemplo, en la Web aparece una gran cantidad de grficos .gif, y cuando
Unisys plante el pago de royalties para su uso, mucha gente pas a usar el formato
.jpg, pero los navegadores no los soportan y utilizar imgenes binarias supone
mucho tiempo, incluso cuando se comprimen. Al objeto de superar esta situacin
apareci la Recomendacin Scalable Vector Graphics, donde un grfico vectorial
viene definido por la geometra de la imagen y no como un "bitmap. SVG facilita la
definicin de una semntica para la definicin de los elementos que confortan una
213
imagen, siempre basndose en la definicin de coordenadas que pueden ser
especificados por medio de archivos XML.
Aclaremos que los formatos vectoriales no son adecuados para fotos de calidad,
sino para ilustraciones elaboradas con lneas, tales como los logos. Adobe Ilustrator
es un ejemplo de una aplicacin grfica que trabaja con formatos de vectores SVG,
que permite crear grficos en un archivo de texto, que pueden ser usados
simultneamente para su presentacin en la Web o para su impresin. La ventaja
de un archivo SVG reside en que ocupa mucha menos memoria que su
correspondiente .if o #jp, y en que si se necesita usar la imagen varias veces en
una misma pgina, slo hay que cargarla una vez; una vez cargad, se puede
escalar, hacerla objeto de rotaciones, etc., y por supuesto poderla mostrar todas las
veces que sea necesario.
4M*L O4&nchroni7ed Multimedia *nte'ration Lan'ua'e@. El uso de archivos
multimedia en la Web no ha dejado de crecer y valga como ejemplo la actual
explosin de animaciones accesibles en la Web. Para estos desarrollos multimedia
W3C desarroll SMIL, un lenguaje basado en XML que permite crear presentaciones
multimedia con funcionalidades tales como grficos animados, sonidos y la
posibilidad de un cierto nivel de interaccin con la presentacin, ya que se pueden
incorporar hiperenlaces.
SMIL al basarse en XML es ms portable que otros formatos multimedia
propietarios y adems, est diseado para poder trabajar con otros vocabularios
XML, como SVG que utilizado conjuntamente con SMIL constituye una alternativa
muy interesante frente s formatos propietarios desarrollados para la Web inicial.
YoiceXML. La interaccin de los sistemas de telefona en la Web ha dado como
resultado la posibilidad del desarrollo de portales de voz. As, marcando un nmero
telefnico que est asociado a un documento Web y por medio de una pasarela, se
tiene la posibilidad de interactuar con documentos XML, por medio de dilogos
utilizando la voz. Con ello se obtiene informacin que reside en el servidor, bien en
forma textual (archivos o bases de datos) bien con sonidos pregrabados. En esta
perspectiva, VoiceXML es un lenguaje de marcado basado en XML que permite
describir la interaccin en la Web basada en dilogos.
Es necesario indicar que VoiceXML tiene pocas opciones para conferencias
telefnicas, ya que las llamadas que involucran a ms de dos partes, u otras
funciones avanzadas, no estn soportadas por este lenguaje. Para superar esta
carencia han surgido determinadas opciones (como CCXML) diseadas para
complementar a VoiceXML suministrando un soporte de control de llamadas,
funciones de telefona avanzada y otros sistemas de dilogos, con el objetivo de
integrarse con un intrprete VoiceXML, as como otros sistemas de control basados
en llamadas telefnicas.
214
44ML O4eech 4&nthesis Mar9u Lan'ua'e@. Partiendo del hecho de que el
marcado puede conseguirse tanto automticamente (como por ejemplo por medio
de XSLT o por CSS3) como a travs de un operador un humano, SSML ha sido
diseado para proporcionar un lenguaje de marcado basado en XML que permita y
facilite la generacin de sintaxis de voz en distintas aplicaciones; su desarrollo est,
en estos momentos, en plena evolucin especialmente para las lenguas ms
universales.
*nteraccin Multimodal. Con la evolucin de los dispositivos mviles como
mecanismo para interactuar con la Web ha surgido la posibilidad de utilizar modos
de interaccin con un documento Web mediante un dispositivo, como por ejemplo,
realizar una peticin utilizando la voz y recibir una respuesta utilizando la voz y
recibir una respuesta utilizando un formato visual o como un documento basado en
XHTML. As existen distintas estandarizaciones promovidas por el W3C en relacin
con la interaccin multimodal, como XV (consistente en una combinacin de XHTML
y VoiceXML para describir interaccin multimodal) o el lenguaje SALT (Speech
Application Language Tags), de forma que en un futuro, no muy lejano, es posible
que VoiceXML, SALT y CCXML se fusionen en un solo estndar.
0econocimiento de Tinta $i'ital. *n9ML. Con el incremento de la disponibilidad
de dispositivos electrnicos con interfaces de entrada especficos, como un lpiz para
introducir y manipular informacin, las aplicaciones Web deben ser ms eficaces en
el manejo de este tipo de entrada. La escritura manual es una modalidad de entrada
que resulta muy familiar para la mayora de los usuarios puesto que es la forma en
que cada uno aprende en la escuela. Por tanto, es posible que muchos usuarios
tiendan a utilizar esta alternativa como modo de entrada y control cuando est
disponible.
InkML es un formato de datos XML para representar la entrada de datos que es
introducida con una pluma o aguja electrnica para una electrnica para un sistema
multimodal y que soporta una representacin completa y exacta de la llamada "tinta
digital. Por ejemplo, adems de la posicin de la pluma, en un cierto lapso de
tiempo, InkML permite la grabacin de la informacin adaptada a las caractersticas
concretas del dispositivo del traductor que se utilice, as como conseguir un
comportamiento dinmico detallado para soportar aplicaciones tales como
reconocimiento y autentificacin de la escritura de una persona determinada, de
forma anloga a como trabajar la grafologa tradicional.
1L#,#,# 4e'uridad e documentos XML
Los aspectos relacionados con la seguridad no han dejado de ganar importancia, a
medida que la Web ha ido explotando como el gran sistema distribuido para publicar
215
y compartir informacin, de hecho la Seguridad es en estos momentos unas de las
especialidades telemticas ms sensibles e importantes. En esta lnea, se han
desarrollado esfuerzos que permitan proteger tanto la totalidad de un documento
XML como determinados elementos o partes del mismo, lo que permite controlar el
acceso a datos crticos que no necesariamente requieran ser compartidos (por
ejemplo el nmero telefnico de la residencia de un funcionario, o el nmero de
cuenta bancaria de un empleado). Como es sabido, las tcnicas de seguridad tienen
una doble vertiente que se ha reproducido en el campo del XML. La seguridad
informtica ha desarrollado tecnologas con dos objetos:
a) Mantener el secreto de la informacin manejada, para lo que hay que
proporcionar la citada proteccin parcial o total del contenido de un
documento. Como es sabido, ello supone encriptar la informacin, de forma
que slo la persona o agente autorizado para ello tenga acceso a la misma.
Para el caso de tener que manejar documentos XML existen una serie de
tecnologas conocidas como XML +ncrition que adaptan las tcnicas
criptogrficas para su uso mediante correspondiente lenguaje basado en XML.
b) Considerando que en un entorno de publicacin eficiente y rpido como es la
Web cada da adquiere ms importante al conocer quin de fe de que la
informacin disponible en un documento es buena y en consecuencia se
responsabiliza de ella (por ejemplo, quien a redactado un documento resumen
de un proyecto en una compaa o en un centro de investigacin), es
necesario contar con mecanismos que identifiquen y garanticen el remitente o
autor de la misma. El concepto de firma digital se extiende para el caso de
documentos XML, en lo que se llama XMLR4i'nature, dirigido a posibilitar la
inclusin de la firma digital, con todo lo que ello supone, a la hora de publicar
un documento.
1L#,#2# 0$A & Web sem=ntica
Uno de los principales problemas con los que se enfrenta la Web es su propio
crecimiento, de forma que a medida que el nmero de sitios Web aumenta, la
organizacin y procesado de la informacin accesible se incrementa
exponencialmente necesitando cada vez ms esfuerzo para acceder a la que
realmente interesa en cada situacin. Uno de los mecanismos que ha desarrollado
W3C para gestionar el procesado automtico de esta informacin es Resource
Description Framework (RDF), consistente bsicamente en un formato basado en
XML para expresar metadatos referidos a la informacin existente en la Web.
El objetivo de RDF es crear un mtodo para describir informacin sobre la propia
Web, de forma que se puedan describir distintos recursos de una forma consistente,
216
con lo que al menos tericamente se facilita la clasificacin, localizacin y
catalogacin automtica de los recursos existentes en la Web. RDF se basa en el uso
de tripletas: sujeto/predicado/objeto. Esta representacin se basa en una estructura
de grafos y para su serializacin en XML se emplea una sintaxis desarrollada para
ello, conocida como XML/RDF.
Por otra parte, en bsqueda de una semntica que describa los recursos en la Web
que vaya ms all de una simple definicin de una estructura de datos, se ha
planteado la necesidad de definir relaciones entre conceptos, as como restricciones
de dominio y rango entre ellos, que faciliten la definicin de reglas y en
consecuencia un procedimiento "inteligente de estos recursos. Esta definicin
semntica, por otra parte permite indicar, por ejemplo, que una etiqueta
denominada "toro es una figura geomtrica en un determinado contexto, o un
animal en otro escenario referencial. En este contexto Tim Berners-Lee propuso el
concepto de Web Semntica con la que se pretende automatizar al mximo el
manejo de la informacin presente en la red, adems de perseguir el objetivo de que
los documentos incorporen un determinado significado semntico que pueda ser
"comprendido directamente por los computadores, sin necesidad de una
intervencin humana.
Dentro de la arquitectura de la Web Semntica se ha incluido a XML como capa
bsica para la definicin sintctica, a RDF como la siguiente capa y para cumplir
todos sus objetivos ha surgido OWL (Ontology Web Language) diseado para
aplicaciones que precisen procesar el contenido de la informacin, ms que hacerla
intangible a los humanos. El objetivo es superar la muy reducida capacidad actual
que de interpretacin del contenido de la Web tiene una maquina, para lo que se
proporciona un vocabulario adicional, junto con una semntica formal. De hecho RDF
y OWL son lo estndares de la Web Semntica al proporcionar un marco para que
las diferentes mquinas "usuario puedan compartir la misma informacin de forma
automtica, al "entenderla, incluso sin que utilicen el mismo software.
1L#,#5# $escribir caacidades de disositivo & re(erencias de usuario
Con la proliferacin de los diversos dispositivos existentes con capacidad de
desplegar contenidos Web (estimados en estos momentos en unos 600) surgi la
necesidad de crear un marco de trabajo que permitiera a un dispositivo comunicar
sus propias caractersticas al servidor, para que ste pueda crear automticamente
un contenido adaptado a las capacidades del dispositivo. En este contexto surgen las
llamadas tecnologas CC6PP OComosite Caabilities Pre(erence Pro(ile@#
CC/PP proporciona el equivalente a los campos en su esquema de una base de
datos, as como el modelo asociado a ellos, al objetivo de poder describir tanto las
217
capacidades de los dispositivos como las preferencias de usuarios, en lo referente a
la forma como desean y deben recibir la informacin solicitada.
CC/PP fue diseado para ajustarse a los planteamientos de la Web semntica, y
constituye una aplicacin de RDF. Aunque CC/PP por s mismo no define un
vocabulario en el sentido de una aplicacin XML, si no ms bien especifica un
lenguaje genrico que puede ser utilizado para construir estos vocabularios, con los
que la Web puede enfrentarse a la citada y creciente variedad de los dispositivos.
Es relevante sealar que el consorcio de compaas de telefona mvil OMA (Open
Mobile Alliance, antes WapForum) ha definido UAProf (User Agent Profile), que
constituye un marco basado en CC/PP que incluye un vocabulario basado en
RDF/XML para describir las capacidades del dispositivo, del agente de usuario, de la
red, etc., as como un protocolo para transformar el perfil del dispositivo,
entendiendo como tal una instancia del vocabulario asociada a un determinado
perifrico.
1L#,#8# *nteraccin con alicaciones distribuidas. 4ervicios Web
Si bien para la interaccin con datos en la Web contamos con los portales Web, para
la interaccin con aplicaciones, la evolucin de los objetivos distribuidos ha dado
lugar a los servicios Web, con lo que es posible desarrollar un determinado servicio o
aplicaciones que reciba unos parmetros de entrada y automticamente genere una
determinada salida. En los servicios Web nuevamente se ha establecido XML como
formato de intercambio de documentos sobre el que se basa el protocolo SOAP. Con
lo dicho, resulta evidente la necesidad de registrar la presencia de esta aplicacin en
un directorio (de tipo pginas amarillas) de servicios para que se pueda recurrir al
ms adecuado o conveniente.
Cuando se ponen en relacin datos con maquinas o servicios, el objetivo es que
los computadores cooperen de forma que se utilice el Web para mejorar el confort
del usuario, introduciendo funcionalidades tales como informaciones y catlogos en
tiempo real, comercio electrnico, servicios en lnea (bolsa, traducciones,
meteorologa), recursos de clculo distribuido, etc. El objetivo consiste en que el
usuario llame a esas funciones por la Web, y que los datos sean transferidos y
devueltos por estas funciones.
En su conjunto, todo ello conduce a los llamados Servicios Web cuyos elementos
principales son la transferencia de datos (basados en el citado protocolo SOAP), la
descripcin de interfaces (WSDL), la presentacin de formularios adaptados a cada
aplicacin (Xform) y una plyade (firmas, escriptado, etc.) de mltiples desarrollos
relacionados con la seguridad y otros aspectos bsicos de las transacciones a travs
218
de la Web. Todas estas tecnologas estn desarrolladas en XML y actualmente ya
estn plenamente accesibles.
1L#,#K# XML & :ases de datos
Aunque en XML siempre hemos hablado de "documento conviene recordar que
existe una doble visin de este concepto, por un lado la que tiene que ver con su
sentido tradicional (libros, artculos, peridicos, etc.) y por otro, una ms centrada
en los datos y en su gestin. Esta ltima enlaza con un campo ms amplio de la
informtica, como es el almacenamiento y configuracin de datos, las informaciones
sobre inventarios, y en general todo lo relacionado con las Bases de Datos. Por ello
se han desarrollado herramientas para trabajar en XML con grandes bases
documentales, tales como bibliotecas y almacenes de documentos. De hecho la
memoria de proveedores de sistemas de gestin de bases de datos han trabajado
muy duro para incorporar la compatibilidad con XML en sus productos (Oracle, IBM,
Microsoft, etc.). En el caso de los grandes documentos, como manuales tcnicos,
diccionarios, enciclopedias, etc., desde hace ms de una dcada se ha venido
trabajando con SGML y ello ha permitido incorporar XML a estas tcnicas sin
mayores dificultades.
Sin embargo, la experiencia de trabajar con bases de datos documentales o
tradicionales pone de manifiesto dos cuestiones claves: la necesidad de un diseo
correcto de su estructura (el esquema), y que los mejores datos del mundo puedan
ser intiles sin un buen sistema de consulta. Como sabemos W3C ha creado
sistemas de consulta XQuery, con la estructura de documentos XML en la cabeza,
para proporcionar mecanismos basados en XPath para localizar datos en
documentos XML, el paso siguiente ha sido pasar a considerar estos documentos
almacenados bien en Bases de Datos relacionados u orientadas a objeto bien en
sistemas de archivos ms simples y proporcionar procedimientos que permitan su
explotacin, tratando de superar algunas de las deficiencias que se enunciaron al
comprar en el Capitulo 7, la gestin de la documentacin XML con las posibilidades
del SQL en las bases de datos relacionales.
Los mecanismos empleados por cada sistema de gestin de datos para dar soporte
a la interaccin con XML o la creacin de vistas temporales de los datos en formato
XML, as como las ventajas y desventajas de las diferentes opciones, quedan fuera
del alcance de este libro, aunque indudablemente constituyen un campo de un gran
inters que estn siendo objetivo, en estos momentos, de desarrollos muy
importantes.
219
1L#2# Alicaciones de XML en di(erentes dominios del conocimiento#
Con el contenido de tecnologas citadas hasta ahora, se est cambiando no slo la
forma en la que se intercambian y publican una gran variedad de datos en la Web,
sino tambin la forma como se gestiona la informacin en el seno de las
organizaciones y empresas, siendo muchos los grupos que actualmente estan
definiendo nuevos formatos para el intercambio en cada sector o rea particular. En
consecuencia. las ventajas de XML en relacin con el intercambio eficiente de
documentos han llevado a miembros de muy diferentes reas del conocimiento a
plantearse la utilizacin de XML en sus dominios respectivos.
Este uso y XML ha estado enfocado principalmente a la definicin de DTDs o
Esquemas XML que definen la estructura de los vocabularios que son intercambios
por los miembros de estas comunidades. Algunos ejemplos de estos son MathML
creado por la comunidad de matemticas, y XBRL(eXtensible Busness Reporting
Language) un esquema XML que tiene como fin describir los vocabularios presentes
en estados financieros y contables, entre otros muchos.
La relacin que sigue es un intento de clasificacin, tomado en diciembre de 2004
de la direccin: http://www.service-architecture.com/xml/articles/index.html. Por
razones obvias mantenemos la forma inglesa, ya que es as como inevitablemente
se acaban designando los distintos vocabularios que estn apareciendo.
TABLA 10.1. Relacin de vocabularios Comunes y Especficos.
A modo de ejemplos, dentro de AinanceXML encontramos:
eXtensible Busness Reporting Language
Financial Infirmation eXchange (FIX) Protocol
Financial products Markup Language (FpML)
Interactive Financial Exchange (IFX)
Markup Data Definition Language (MDDL)
Open Financial Exchange (OFX) XML Schema
Research Information eXchange Markup Language
SWIFTStandards XML
y dentro de lo legalXML:
Global Justice Extensible Markup Lenguage (XML)
LegalXML Electronic Court Filing
LegalXML eContracts
LegalXML eNotary
LegalXML Integrated Justice
220
LegalXML Legislative Documents
LegalXML Online Dispute Resolution (OdrXML)
LegalXML Legal Transcripts
LegalXML Subcriber Data Handover Interface (SDHI)
Sirvan estos ejemplos para mostrar la cantidad y variedad de lenguajes XML
existentes en la actualidad, cosa que no va a impedir que sigan creciendo en los
prximos aos.
1L#5# +ntornos de Pro'ramacin & XML

Con la llegada de Java, y de la infraestructura para poder manejar objetivos, (RMI,
CORBA/IOP, OLE/COM, etc.) en la Web han ido apareciendo y seguirn hacindolo,
objetos distribuidos que ofrecer una extensibilidad importante. Ello llev a
plantearse el desarrollo de entorno de programacin que soportan tambin XML.
Este movimiento ha sido tan rpido, que en estos momentos son muchas las
herramientas que permiten que una gran cantidad de lenguajes y entornos de
programacin trabajen con XML.
Es obligatorio sealar que, a pesar de sus orgenes distintos, Java y XML se han
complementado perfectamente a la hora de producir aplicaciones que trabajan en la
Web; ello se debe a que ambos proporcionan mecanismos para desarrollos
independientes de la plataforma, de forma que, mientras JAVA proporciona
programas, XML se cuida de los documentos. La rpida aparicin de analizadores
XML escritos en Java evit reinventar la rueda, y Java puede usarse con XML tanto
desde el lado del cliente como del lado del servidor. Con ello se puede construir casi
cualquier cosa, desde algo genrico como un editor XML. hasta un software muy
especifico como puede ser un inventario de un almacn.
Para responder a este reto. Microsoft lanz su iniciativa .NET, con un cojito de
herramientas, no exactamente un lenguaje de programacin, diseadas teniendo
XML en su transformo como tecnologa suplementaria; con ello se pretende
desarrollar aplicaciones portables, robustas y fciles de construir, y esta idea va
camino de configurarse de forma definitiva en las ltimas y prximas versiones de
sus sistemas operativos.
A partir de la evolucin de las tecnologas de "scripts del lado del servidor,
muchas de las capacidades que hemos descrito se han integrado en las ltimas
versiones de lo entornos de desarrollo, siendo en la actualidad los dos grandes
entornos para la interaccin dinmica del servidor: J2EE (Java 2 Enterprice Edition)
y .NET. No obstante hay que sealar que existen otros entornos para el uso del XML.
Unos estn pensados desde el lado del cliente, como JavaScript donde es comn el
procesamiento de un rbol XML basndose en DOM, mientras que otros ven la tarea
221
desde el lado del servidor (PHP, PERL, etc.) en cuyo caso es posible hacer
transformaciones de datos XML, de forma similar a como trabaja J2EE.
Respecto a los lenguajes hay que resear la experiencia de una gama que va
desde lenguajes como ECMASScript (un lenguaje de "scripting estndar para
industria basado en JavaScript) que slo proporciona la gramtica y funcionalidades
de los tipos bsicos (cadena, objeto, nmero, etc.)hasta lenguajes pensados para
manejar texto como PERL, que ofrece medios para trabajar con XML, desde el lado
del servidor para una gran variedad de plataformas de Unix a Windows, pasando por
todos los desarrollos basados en Python y lenguajes semejantes. El estudio y
manejo de estas posibilidades, caen fuera de la ptica y objetivos del presente
texto, aunque s hay que sealar que la eleccin de una de las distintas opciones
posibles es una de las decisiones ms importantes para quien vaya a programar
usando XML.











222