Page 1
NOVATICA jul../ago. 2002 nº158
Edición digital/ ©ATI 2002 1
SUMARIO
En resumen:
¿ASCII o esperanto?
3
Rafael Fernández Calvo
Monografía:
«XML: ¿el ASCII del siglo XXI?»
(En colaboración con
Upgrade
)
Editores invitados:
Luis Sánchez Fernández y Carlos Delgado Kloos
Presentación. XML: panorámica de una revolución
5
Luis Sánchez Fernández, Carlos Delgado Kloos
XML: el ASCII del siglo XXI
8
Luis Sánchez Fernández, Carlos Delgado Kloos
XML, el desarrollo de nuevas aplicaciones empresariales
y la industria del software
13
Enrique Bertrand López de Roda
Aplicación de los Lenguajes de Marcado XML
en el Desarrollo de Software
17
Baltasar Fernández-Manjón, Alfredo Fernández-Valmayor,
Antonio Navarro, José Luis Sierra
Viabilidad práctica de la evaluación de consultas
en la Web Semántica
22
José Francisco Aldana Montes, Antonio César Gómez,
Nathalie Moreno Vergara, María del Mar Roldán García
Firma y cifrado digital con XML
27
Antonio F. Gómez Skarmeta, María Encarnación Martínez González,
Eduardo Martínez Graciá, Gregorio Martínez Pérez
Realidades y posibilidades de XML en la normalización
de la TV digital con MHP (
Multimedia Home Platform
)
31
Alberto Gil Solla, José J. Pazos Arias, Cándido López García,
Manuel Ramos Cabrer, José Carlos López Ardao, Raúl F. Rodríguez Rubio
Aplicación de XML en el campo del periodismo
36
Luis Sánchez Fernández, Carlos Delgado Kloos, Vicente Luque Centeno,
Mª del Carmen Fernández Panadero, Laura Martínez Bermejo
Business Maps
: aplicación de los
Topic Maps
en B2B
40
Marc de Graauw
Secciones Técnicas
Bases de Datos
Ontologías en Federación de Bases de Datos
45
Nieves R. Brisaboa, Miguel R. Penabad, Ángeles S. Places,
Francisco J. Rodríguez
Propuesta de actualización del currículum de Bases de Datos
54
Coral Calero Muñoz, Mario Piattini Velthuis, Francisco Ruiz González
Interacción Persona-Computador
Ocultos pero no ausentes: los ciegos y la Informática (y II)
59
Víctor M. Maheux
eEurope 2002: accesibilidad de los sitios web públicos y
de su contenido (extracto)
62
Comunicación de la Comisión de las Comunidades Europeas
(presentación de Julio Abascal González)
Profesión informática
La regulación profesional de los Auditores
de Sistemas de Información
66
Manuel Palao
Referencias autorizadas
70
Sociedad de la Información
Programar es crear
No taléis el bosque por culpa de los árboles
73
25º Concurso Internacional de Programación ACM (2001): problema D
Crucigramas: solución
74
Cristóbal Pareja Flores, José Alberto Verdejo López
Asuntos Interiores
Programación de Novática
77
Normas de publicación para autores / Socios Institucionales de ATI
78
Monografía del próximo número:
«
Inteligencia Artificial
»
Novática
, revista fundada en 1975, es el órgano
oficial de expresión y formación continua de ATI
(Asociación de Técnicos de Informática).
Novática
publica también
Upgrade
, revista digital de CEPIS
(
Council of European Professional Informatics
Societies
), en lengua inglesa.
<http://www.ati.es/novatica/>
<http://www.upgrade-cepis.org/>
ATI es miembro de CEPIS (
Council of European
Professional Informatics Societies
) y tiene un
acuerdo de colaboración con ACM (
Association for
Computing Machinery
). Tiene asimismo acuerdos de
vinculación o colaboración con AdaSpain, AI
2
y ASTIC
CONSEJO EDITORIAL
Antoni Carbonell Nogueras, Francisco López Crespo, Julián Marcelo Cocho,
Celestino Martín Alonso, Josep Molas i Bertrán, Roberto Moya Quiles, César
Pérez Chirinos, Mario Piattini Velthuis, Fernando Piera Gómez (Presidente del
Consejo), Miquel Sàrries Griñó, Carmen Ugarte García, Asunción Yturbe Herranz
Coordinación Editorial
Rafael Fernández Calvo
<rfcalvo@ati.es>
Composición y autoedición
Jorge Llácer
Administración
Tomás Brunete, María José Fernández
SECCIONES TECNICAS: COORDINADORES
Arquitecturas
Jordi Tubella (DAC-UPC) <
jordit@ac.upc.es>
Bases de Datos
Coral Calero Muñoz, Mario G. Piattini Velthuis
(Escuela Superior de Informática, UCLM)
<Coral.Calero@uclm.es>, <mpiattin@inf-cr.uclm.es>
Calidad del Software
Juan Carlos Granja (Universidad de Granada) <
jcgranja@goliat.ugr.es>
Derecho y Tecnologías
Isabel Hernando Collazos (Fac. Derecho de Donostia, UPV)
<ihernando@legaltek.net>
Enseñanza Universitaria de la Informática
Cristóbal Pareja Flores (Dep. Sistemas Informáticos y Programación-UCM)
<cpareja@sip.ucm.es>
Informática Gráfica
Roberto Vivó (Eurographics, sección española)
<rvivo@dsic.upv.es>
Ingeniería del Software
Luis Fernández (PRIS-E.I./UEM) <
lufern@dpris.esi.uem.es>
Inteligencia Artificial
Federico Barber,Vicente Botti (DSIC-UPV)
<{vbotti, fbarber}@dsic.upv.es>
Interacción Persona-Computador
Julio Abascal González (FI-UPV) <
julio@si.ehu.es>
Internet
Alonso Álvarez García (TID)
<alonso@ati.es>
Llorenç Pagés Casas (Atlante) <
pages@ati.es>
Lengua e Informática
M. del Carmen Ugarte (IBM)
<cugarte@ati.es>
Lenguajes informáticos
Andrés Marín López (Univ. Carlos III)
<amarin@it.uc3m.es>
J. Ángel Velázquez (ESCET-URJC)
<a.velazquez@escet.urjc.es>
Libertades e Informática
Alfonso Escolano (FIR-Univ. de La Laguna) <
aescolan@ull.es>
Lingüística computacional
Xavier Gómez Guinovart (Univ. de Vigo) <
xgg@uvigo.es>
Manuel Palomar (Univ. de Alicante) <
mpalomar@dlsi.ua.es>
Profesión informática
Rafael Fernández Calvo (ATI)
<rfcalvo@ati.es>
Miquel Sarries Grinyó (Ayto. de Barcelona)
<msarries@ati.es>
Seguridad
Javier Areitio (Redes y Sistemas, Bilbao)
<jareitio@orion.deusto.es>
Sistemas de Tiempo Real
Alejandro Alonso, Juan Antonio de la Puente (DIT-UPM)
<{aalonso,jpuente}@dit.upm.es>
Software Libre
Jesús M. González Barahona, Pedro de las Heras Quirós (GSYC, URJC)
<{jgb,pheras}@gsyc.escet.urjc.es>
Tecnología de Objetos
Esperanza Marcos (URJC)
<e.marcos@escet.urjc.es>
Gustavo Rossi (LIFIA-UNLP, Argentina)
<gustavo@sol.info.unpl.edu.ae>
Tecnologías para la Educación
Benita Compostela (F. CC. PP.- UCM)
<benita@dial.eunet.es>
Josep Sales Rufí (ESPIRAL)
<jsales@pie.xtec.es>
Tecnologías y Empresa
Pablo Hernández Medrano
<phmedrano@terra.es>
TIC para la Sanidad
Valentín Masero Vargas (DI-UNEX)
<vmasero@unex.es>
Las opiniones expresadas por los autores son responsabilidad exclusiva de
los mismos. Novática permite la reproducción de todos los artículos, salvo
los marcados con
o
copyright
, debiéndose en todo caso citar su procedencia
y enviar a Novática un ejemplar de la publicación.
Coordinación Editorial y Redacción Central (ATI Madrid)
Padilla 66, 3º, dcha., 28006 Madrid
Tlf.914029391; fax.913093685
<novatica@ati.es>
Composición, Edición y Redacción ATI Valencia
Palomino 14, 2ª, 46003 Valencia
Tlf./fax 963918531
<secreval@ati.es>
Administración, Subscripciones y Redacción ATI Cataluña
Via Laietana 41, 1º, 1ª, 08003 Barcelona
Tlf.934125235; fax 934127713
<secregen@ati.es>
Redacción ATI Andalucía
Isaac Newton, s/n, Ed. Sadiel, Isla Cartuja 41092 Sevilla
Tlf./fax 954460779
<secreand@ati.es>
Redacción ATI Aragón
Lagasca 9, 3-B, 50006 Zaragoza
Tlf./fax 976235181
<secreara@ati.es>
Redacción ATI Asturias-Cantabria
<gp-astucant@ati.es>
Redacción ATI Castilla-La Mancha
<gp-clmancha@ati.es>
Redacción ATI Galicia
Recinto Ferial s/n, 36540 Silleda (Pontevedra)
Tlf.986581413; fax 986580162
<secregal@ati.es>
Publicidad:
Padilla 66, 3º, dcha., 28006 Madrid
Tlf.914029391; fax.913093685
<novatica@ati.es>
Imprenta:
9·Impressió S.A., Juan de Austria 66, 08005 Barcelona.
Depósito Legal: B 15.154-1975
ISSN: 0211-2124; CODEN NOVAEC
Portada:
Antonio Crespo Foix /
ATI 2002

Page 2
NOVATICA jul../ago. 2002 nº158
Edición digital/ ©ATI 2002 3

Page 3
NOVATICA/UPGRADE jul../ago. 2002 nº158
Edición digital/ ©ATI 2002 5
MONOGRAFÍA
XML: ¿el ASCII del siglo XXI?
Nos parece muy acertado el que
Novática
y
Upgrade
hayan
decidido dedicar un monográfico a XML (
eXtensible Markup
Languaje
) . Desde su aparición impulsado por el
World Wide Web
Consortium
(W3C) a finales de los años 90, XML ha supuesto una
revolución en el mundo de la informática. XML está siendo
aplicado en multitud de campos y para diversos fines: archivo
electrónico y gestión de contenidos, publicación web, intercambio
electrónico de documentos, formato interno de herramientas, soft-
ware, comercio electrónico, educación, y tantos otros campos que
sería imposible reflejar aquí. Por citar algunos campos menos
obvios, mencionemos: química, biología, teología, turismo, dere-
cho, sanidad. Para una revisión amplia de los campos de aplicación,
recomendamos el excelente trabajo de recopilación realizado por
Robin Cover, que se puede ver en <http://xml.coverpages.org/>.
Aunque, como ya se ha dicho, XML es un estándar del W3C, sin
embargo sus aplicaciones exceden del ámbito estricto de la Web. Por
este motivo, hemos querido titular esta presentación del monográfico
como «XML, un estándar no sólo para la Web», para indicar que es un
estándar que ha nacido en el mundo Web y que se utiliza dentro y fuera
de su ámbito. XML es una forma de representar datos que han de circular
por la red y por ello no está ligado necesariamente a su presentación en
un navegador.
En este monográfico sobre XML contamos tanto con artículos
técnicos como con artículos que representan casos de estudio del
uso de XML en diferentes campos. El monográfico comienza con
un artículo introductorio «
XML: ASCII del siglo XXI
» en el que se
incluye un breve apunte histórico, se presenta el lenguaje XML y
algunos de los estándares asociados más importantes y se discuten
los motivos del éxito de XML.
A continuación viene un artículo, «
XML, el desarrollo de nuevas
aplicaciones empresariales y la industria del software
», que en
parte complementa al anterior. En este artículo se da una visión de
XML desde el punto de vista empresarial y se habla de herramien-
tas de soporte al estándar que están siendo desarrolladas por
diferentes empresas de software.
A continuación vienen varios artículos técnicos en los que se
presentan desarrollos o tecnologías basados en XML: «
Aplicación
de los lenguajes de marcado XML en el desarrollo de software
»,
«
Viabilidad práctica de la evaluación de consultas en la web
semántica
» y «
Firma y cifrado digital con XML
».
Editores invitados
Luis Sánchez Fernández
es Profesor Titular de Universidad del
Departamento de Ingeniería Telemática de la Universidad Carlos III de
Madrid. Posee el grado de Doctor Ingeniero de Telecomunicación por la
Universidad Politécnica de Madrid. Es autor de más de 30 publicaciones
en revistas y congresos nacionales e internacionales. Ha participado en
varios proyectos de investigación nacionales e internacionales. Actual-
mente, sus intereses principales se centran en las siguientes áreas:
publicación electrónica, periodismo electrónico y XML. Socio de ATI.
Carlos Delgado Kloos
es Catedrático en la Universidad Carlos III de
Madrid y Director del Departamento de Ingeniería Telemática y del
Máster en Comercio Electrónico en esta Universidad. Sus intereses
incluyen Lenguajes y Técnicas de Diseño, así como aplicaciones
basadas en Tecnología Internet, tales como la publicación electrónica,
la tele-educación o el comercio electrónico. Ha liderado varios proyectos
de investigación tanto a nivel europeo, como nacional y bilateral (España-
Alemania y España-Francia). Ha publicado más de 60 artículos cientí-
ficos en congresos y revistas nacionales e internacionales. Además ha
escrito un libro y co-editado otros cuatro. Entre los cargos que ha
ocupado u ocupa se encuentran los siguientes: vicepresidente del
comité técnico nº 10 de IFIP, secretario del grupo de trabajo nº 10.5 de
IFIP, miembro del Consejo editorial de la revista
Formal Aspects of
Computing
publicada por Springer-Verlag, subdirector de Ingeniería
de Telecomunicación en la Universidad Carlos III de Madrid, gestor del
Programa Nacional de Tecnologías de la Información y las Comunica-
ciones en el Ministerio de Ciencia y Tecnología español y miembro de
comités de programa de más de 40 congresos y simposios, entre los que
cabe resaltar la vicepresidencia del Comité de Programa del Congreso
Mundial de Informática de IFIP. Pertenece a diversas asociaciones
extranjeras y españolas, entre ellas ATI, y es frecuente colaborador de
Novática
, revista de cuyo Consejo Editorial fue miembro.
Presentación. XML: pano-
rámica de una revolución
Luis Sánchez Fernández, Carlos Delgado Kloos
Depto. de Ingeniería Telemática, Universidad Carlos
III de Madrid
<luis@it.uc3m.es>, < cdk@it.uc3m.es>
Los siguientes dos artículos se pueden encuadrar como casos de
estudio, uno sobre televisión digital («
Realidades y posibilidades
de XML en la normalización de la TV digital con MHP (Multimedia
Home Platform)
») y otro sobre periodismo («
Aplicación de XML
en el campo del periodismo
»).
Finalmente, se ha incluido un artículo seleccionado del congre-
so XML Europe 2002, el congreso más importante en el campo
de XML en nuestro continente, celebrado en Barcelona el
pasado mes de mayo. Se titula «
Business Maps: aplicación de
los Topics Maps en B2B
» y en el se describe la definición de
correspondencias entre diferentes ontologías en el campo del
B2B.
El lector interesado puede completar la panorámica presentada en
esta monografía visitando alguna de las páginas Web dedicadas a
XML cuyos enlaces presentamos a continuación (ver «Referencias
útiles sobre XML»). Además, damos referencias a dos libros
dedicados a XML, de entre los múltiples textos que están apare-
ciendo continuamente sobre este lenguaje (una búsqueda en <http:
//www.amazon.com> de libros sobre XML dio 359 resultados).
No queremos terminar esta presentación sin agradecer a todos los
autores de los artículos de esta monografía su participación. La
Nota del Editor de Novática:
por razones ineludibles de espacio no se
incluyen en esta monografía los dos siguientes artículos, procedentes
del congreso XML Europe 2002: «
Una nueva cara para cada espectáculo:
prepare su contenido por medio de una efectiva ingeniería de variantes
»,
de
Martina Hemrich
, y «
XML y Word y XML: conversión desde y hacia
documentos XML
» de
Stephan Hermann
.
Dichos artículos serán publicados, en inglés, en el número 4/2002 de
Upgrade
, <http://www.upgrade-cepis.org>, y en próximos números de
Novática
, en español.

Page 4
NOVATICA/UPGRADE jul./ago. 2002 nº158
6 Edición digital/ ©ATI 2002
Glosario
Aplicación XML
: un lenguaje XML definido por medio de una DTD o
un XML Schema que se utiliza en un cierto ámbito.
CSS
:
Cascading Style Sheets
(Hojas de Estilo en Cascada). Hojas de estilo
que permiten definir como presentar documentos XML y también docu-
mentos HTML.
DOM
:
Document Object Model
(Modelo de Objetos de Documento). Es
un interfaz independiente de la plataforma y del lenguaje de programación
utilizado que permite acceder y modificar el contenido o la estructura de
documentos XML y HTML.
DTD
:
Document Type Definition
(Definición de Tipo de Documento). Es
un formato que permite definir la estructura y elementos de una cierta
aplicación XML.
FTP
:
File Transfer Protocol
(Protocolo de Transferencia de Ficheros). Es
un protocolo para la transferencia de ficheros a través de una red de
ordenadores.
HTML
:
HyperText Markup Language
. Es un lenguaje de marcado
utilizado para la creación de documentos que se quieran publicar en la Web.
Estandarizado por el W3C.
HTTP
:
Hypertext Transfer Protocol
(Protocolo de Transferencia de
Hipertexto). Es un protocolo de nivel de aplicación para intercambio de
información hipermedia.
Lenguaje de marcado
: lenguaje que permite añadir marcas a un docu-
mento de texto para dar semántica o describir como presentar el contenido
del documento.
Metadato
: Es un dato que se utiliza para describir o añadir información
sobre otro dato.
Metalenguaje
: en el mundo de la informática, un lenguaje informático
que se utiliza para definir otros lenguajes.
Namespace
: permite identificar una fuente que define un conjunto de
elementos y atributos que son utilizados en un documento XML.
RPC
:
Remote Procedure Call
(Llamada a Procedimiento Remoto). Es un
protocolo que permite que dos aplicaciones que se están ejecutando en
ordenadores conectados a través de una red, puedan comunicarse imitando
la llamada a procedimiento de los lenguajes de programación de alto nivel.
SAX
:
Simple API for XML
(API sencillo para XML). Es una interfaz que
permite acceder al contenido y la estructura de documentos XML. Junto
con DOM son los dos analizadores empleados habitualmente para desarro-
llar herramientas software basadas en XML. SAX no es un estándar del
W3C, sino que es un estándar "de facto".
SGML
:
Standard Generalizaed Markup Language
. Metalenguaje para
definir lenguajes de marcado predecesor de XML.
SOAP
:
Simple Object Access Protocol
(Protocolo de Acceso a Objetos
Sencillo). Es un protocolo basado en XML para realizar invocación remota
de métodos mediante mensajes.
SMTP
:
Simple Mail Transfer Protocol
(Protocolo Simple de Transferen-
cia de Correo Electrónico). Es un protocolo para el intercambio de mensajes
de correo electrónico.
UDDI
:
Universal Description, Discovery and Integration
(Descripción,
Descubrimiento e Integración Universales). Es una iniciativa para crear un
marco independiente de la plataforma para describir servicios, descubrir
compañías e integrar servicios ofrecidos por compañías en Internet.
WML
:
Wireless Markup Language
(Lenguaje de Marcado para Dispo-
sitivos Móviles): lenguaje que se utiliza actualmente para presentar conte-
nido hipertextual en teléfonos móviles y agendas electrónicas.
WSDL
:
Web Services Description Language
(Lenguaje de Descripción
de Servicios Web).
W3C
:
World Wide Web Consortium
. Es el organismo que se encarga de
desarrollar los estándares relacionados con el Web.
XLink
:
XML Linking Language
(Lenguaje de vínculos de XML).
Lenguaje para definir vínculos entre documentos XML.
XML
:
Extensible Markup Language
(Lenguaje Extensible de Marcas).
Es un metalenguaje para definir lenguajes de marcado. Estandarizado por
el W3C.
XML Schema
: Al igual que las DTDs, permite definir como es una cierta
aplicación XML, pero de una forma mucho más precisa.
XPath
:
XML Path Language
(Lenguaje de Rutas XML). Parte de XSL
que permite identificar partes de un cierto documento XML (elementos,
atributos).
XPointer
: Lenguaje que permite identificar puntos de documentos XML.
Es una extensión de XPath y se usa en combinación con XLink.
XQuery
: Es un lenguaje de consultas para XML, bien sobre documentos
XML aislados, bien sobre bases de datos de documentos XML.
XSL
:
eXtensible Stylesheet Language
(Lenguaje Extensible de Hojas de
Estilo). Lenguaje de hojas de estilo para XML estandarizado por el W3C.
Se compone de 3 partes: XPath, XSLT y XSL-FO.
XSLT
:
XSL Transformations
(Transformaciones XML). Parte de XSL
que permite definir como transformar un documento XML en otro
documento en formato XML, HTML o texto plano.
XSL-FO
:
XSL Formatting Objects
(Objetos de Formateado de XSL).
Parte de XSL que permite definir como presentar un documento XML.
Referencias útiles sobre XML
Además de las referencias que aparecen en los artículos de esta
monografía, los lectores interesados en ampliar sus conocimien-
tos sobre XML pueden utilizar los siguientes recursos:
Principales congresos
- XML Europe: <http://www.xmleurope.com>
- XML Conference & Exposition:
<http://www. xml conference.org/xmlusa/>
Libros
-
Richard Anderson, Mark Birbeck, Michael Kay, Steven
Livingstone, Brian Loesgen, Didier Martin, Stephen Mohr,
Nikola Ozu, Bruce Peat, Jonathan Pinnock, Peter Stark,
Kevin Williams.
Professional XML
. Wrox Press Inc. ISBN
1861003110.
-
Benoit Marchal.
XML by Example
. Que. ISBN 0789722429.
Sitios Web
- Extensible Markup Language (XML). World Wide Web
Consortium: <http://www.w3.org/XML>
- Oasis consortium: <http://www.oasis-open.org/>
- XML.org : <http://www.xml.org/>.
- O'Reilly XML.com: <http://www.xml.com/>
- XML Journal. SYS-CON Media:
<http://www.sys-con.com/xml>
- Xmlu.com. División de Architag International:
<http://www.xmlu.com/>
- XML Files. INT Media Group, Incorporated.
<http://www.xmlfiles.com/>
- Peter Flynn. The XML FAQ: <http://www.ucc.ie/xml>
- Joaquín Bravo, Daniel Rodríguez, David Carrero y Alex
Morales. Programación en castellano. XML:
<http://www.programacion.com/direcciones.php?categoria=xml>
- XML-ES (Extensible Markup Language en español). Departa-
mento de Ingeniería Telemática y Departamento de
Biblioteconomía y Documentación. Universidad Carlos III de
Madrid: <http://xml.it.uc3m.es>
- XMLephant, the big XML resource. Cardboard String Media:
<http://www.xmlephant.com/>
- DevX XML Home. DevX Inc: <http://www.xml-zone.com/>
- Web Developers Virtual Library. XML. INT Media Group,
Incorporated: <http://wdvl.com/Authoring/Languages/XML>
- Elliotte Rusty Harold. Cafe con Leche XML News and
Resources: <http://www.ibiblio.org/xml>
- IEEE Internet Computing Online. XML Resources Page:
<http://computer.org/internet/xml>
- XML Web Ring. Web Ring Inc.:
<http://b.webring.com/hub?ring=xml>
- Grupo de noticias de XML: <news:comp.text.xml>
- Netscape XML Developer Central:
<http://developer.netscape.com/tech/xml/index.html>
- Java y XML. Sun Microsystems, Inc:
<http://java.sun.com/xml/>
- IBM XML Zone: <http://www.ibm.com/developer/xml/>
- Microsoft XML Developer Center:
<http://msdn.microsoft.com/xml/default.asp>
- Software AG. The XML Company:
<http://www.softwareag.com/>
- W3Schools: <http://www.w3schools.com/xml/>
mayoría de los autores pertenecen a la red de investigación XML-
ES, subvencionada parcialmente por el Ministerio de Ciencia y
Tecnología a través de una acción especial. Nuestro agradecimien-
to así pues a la financiación de esta iniciativa. Finalmente, quere-
mos dar las gracias a los editores de
Novática
y de
Upgrade
por
habernos ofrecido editar esta monografía y por toda la ayuda que
nos han prestado.

Page 5
NOVATICA/UPGRADE jul./ago. 2002 nº158
8 Edición digital/ ©ATI 2002
MONOGRAFÍA
XML: ¿el ASCII del siglo XXI?
Resumen:
con este artículo los autores pretendemos intro-
ducir al lector en el mundo de XML. Contiene una revisión
de sus orígenes, una pequeña introducción al lenguaje XML
y a los principales estándares asociados al mismo, una
discusión sobre los motivos de su éxito y unas breves
conclusiones.
Palabras clave
: XML, SGML, metalenguaje, metadato, DTD,
World Wide Web.
1. Apunte histórico
Volvamos nuestra mirada hacia los años 80 en los que por
iniciativa de las editoriales de los EE.UU. se definió un
lenguaje que se llamó SGML (
Standard Generalized Markup
Language
). SGML fue sucesor de otro lenguaje, llamado
GML, propietario de IBM, que también tenía su utilidad en
el mundo editorial. Lo que se quería era identificar un
lenguaje en el que se pudiesen separar las dos funciones
principales de relevancia en el mundo editorial, que son los
contenidos y la forma de presentar esos contenidos, en este
caso los libros, las publicaciones. El autor de una publica-
ción es el especialista en el contenido, sin embargo la
editorial es la que puede definir de mejor forma cómo se ha
de presentar ese contenido. SGML permitía definir lengua-
jes de marcado concretos, por tanto se trata de un
metalenguaje, un lenguaje o notación para definir lenguajes.
SGML es por tanto un lenguaje que no tiene nada que ver con
Internet, ni con las redes.
Tim Berners-Lee cuando desarrolló el
World Wide Web
a
finales de los 80 necesitaba un lenguaje para expresar los
contenidos que iban a circular por la red y presentarse a
través del navegador. Entonces utilizó este metalenguaje
SGML como base para definir el lenguaje HTML (
HyperText
Markup Language
) original. HTML fue creciendo muy
rápidamente por los requisitos adicionales que se iban
imponiendo y además de forma desordenada debido a las
pugnas entre las empresas por mantener un liderazgo. Se
fueron incorporando más y más capacidades, más y más
elementos (tablas, fondos, objetos de audio y de video, etc.),
de manera que HTML ampliándose sucesivamente. Pero,
¿hasta cuándo debía crecer HTML? ¿Había de crecer HTML
indefinidamente? Distintos colectivos querían incorporar
sus necesidades particulares. Por ejemplo los matemáticos
reivindicaban que se pudiesen expresar fórmulas matemáti-
cas de una forma correcta (con sus índices, subíndices,
integrales, quebrados, etc.). Pero otros colectivos tenían
exactamente los mismos derechos, los químicos querían
representar fórmulas químicas o los músicos representar
partituras de una manera razonable. Si se daba respuesta a
XML: el ASCII del siglo XXI
Luis Sánchez Fernández, Carlos Delgado Kloos
Depto. de Ingeniería Telemática, Universidad Carlos III
de Madrid
<luis@it.uc3m.es>, <cdk@it.uc3m.es>
Autores
Luis Sánchez Fernández
es Profesor Titular de Universidad
del Departamento de Ingeniería Telemática de la Universidad
Carlos III de Madrid. Posee el grado de Doctor Ingeniero de
Telecomunicación por la Universidad Politécnica de Madrid. Es
autor de más de 30 publicaciones en revistas y congresos
nacionales e internacionales. Ha participado en varios proyec-
tos de investigación nacionales e internacionales. Actualmente,
sus intereses principales se centran en las siguientes áreas:
publicación electrónica, periodismo electrónico y XML. Socio
de ATI
Carlos Delgado Kloos
es Catedrático en la Universidad Car-
los III de Madrid y Director del Departamento de Ingeniería
Telemática y del Máster en Comercio Electrónico en esta
Universidad. Sus intereses incluyen Lenguajes y Técnicas de
Diseño, así como aplicaciones basadas en Tecnología Internet,
tales como la publicación electrónica, la tele-educación o el
comercio electrónico. Ha liderado varios proyectos de investiga-
ción tanto a nivel europeo, como nacional y bilateral (España-
Alemania y España-Francia). Ha publicado más de 60 artículos
científicos en congresos y revistas nacionales e internacionales.
Además ha escrito un libro y co-editado otros cuatro. Entre los
cargos que ha ocupado u ocupa se encuentran los siguientes:
vicepresidente del comité técnico nº 10 de IFIP, secretario del
grupo de trabajo nº 10.5 de IFIP, miembro del Consejo editorial
de la revista
Formal Aspects of Computing
publicada por
Springer-Verlag, subdirector de Ingeniería de Telecomunica-
ción en la Universidad Carlos III de Madrid, gestor del Programa
Nacional de Tecnologías de la Información y las Comunicacio-
nes en el Ministerio de Ciencia y Tecnología español y miembro
de comités de programa de más de 40 congresos y simposios,
entre los que cabe resaltar la vicepresidencia del Comité de
Programa del Congreso Mundial de Informática de IFIP. Perte-
nece a diversas asociaciones extranjeras y españolas, entre
ellas ATI, y es frecuente colaborador de
Novática
, revista de
cuyo Consejo Editorial fue miembro.
todas las diversas peticiones, HTML se convertiría en un
lenguaje monstruoso. No tenía sentido en ese momento,
pues, dar respuesta a todas esas distintas necesidades.
Se pensó: bueno, volvamos a SGML. SGML era un
metalenguaje con el cual se podían definir lenguajes especí-
ficos, aplicaciones concretas para distintos usos. Por tanto,
en lugar de definir un lenguaje de marcado para múltiples
usos, se podía dejar a cada colectivo que se definiese su
propio lenguaje de marcado. Pero había un problema y es
que SGML era muy complejo. SGML tenía unos manuales
muy complicados y además se definió sin tener en cuenta las
teorías conocidas de lenguajes formales y de autómatas, es
decir, no tenía en cuenta el estado del arte para los
procesadores de lenguajes. Era muy complejo definir len-
guajes concretos y era muy complicado definir procesadores

Page 6
NOVATICA/UPGRADE jul../ago. 2002 nº158
Edición digital/ ©ATI 2002 9
para esos lenguajes, que además eran relativamente
ineficientes. De ahí surgió XML.
XML (
eXtensible Markup Language--
Lenguaje Extensible
de Marcas), es una versión simplificada, reducida de SGML,
que quizá quita algo de libertad a la hora de definir lenguajes
concretos, pero da mayor flexibilidad y permite definir
procesadores de lenguajes más eficientes de una forma
mucho más sencilla. Se dice con el 20% del potencial que
tenía SGML se podrían conseguir el 80% de los resultados.
¿Cómo se definen esos lenguajes concretos? Si un matemá-
tico quiere definir su lenguaje marcado concreto --o un
músico, un químico, etc., deciden hacer eso mismo--, tiene
que hacer uso de una notación. Esa notación que ha sido
estandarizada por el W3C el 10 de febrero de 1998 se
denomina DTD (
Document Type Definition
), siguiendo la
tradición de SGML. Un DTD define el tipo concreto de
aplicación que nosotros queremos utilizar.
Sin embargo en mayo de 2001 el W3C especificó otra forma
de definir aplicaciones XML. Se trata de XML Schema. Esta
notación es mucho más potente, expresiva y completa para
definir esos lenguajes concretos. Ahora mismo están por
tanto conviviendo dos notaciones para definir esas aplica-
ciones concretas con las ventajas y las dificultades que
introduce a la hora de que se definan nuevas aplicaciones.
2. Árboles
Vamos a hacer un paréntesis y extraer una cita de un libro que
no tiene nada que ver con Internet ni con las nuevas tecnologías.
Se trata de un extracto del libro
Zen and the Art of Motorcycle
Maintenance
de Robert Pirsig: «
La estructura de conceptos es
llamada formalmente
jerarquía
y desde muy antiguo ha sido
una estructura básica de todo el conocimiento occidental.
Reinos, imperios, iglesias, ejércitos se han estructurado en
jerarquías todos ellos. Los índices de material de consulta están
estructurados así, todo el conocimiento científico y tecnológico
está estructurado así ...
».
Es decir, en todos estos ámbitos hay una cabeza, un rey, un
emperador, un Papa, un general y luego una estructura jerárqui-
ca. Pues bien, esa jerarquía en que nos basamos en todos los
ámbitos de la sociedad occidental es una estructura que nos
sirve también en el contexto de los lenguajes de marcado. XML
no es más que un lenguaje para definir jerarquías. XML permite
representar información jerárquica, pudiendo definir nosotros
como usuarios los elementos de la jerarquía. La jerarquía es lo
que en informática se llama «árbol», donde hay un nodo y
subnodos (subárboles) que cuelgan de ese nodo, elementos que
están subordinados a él de una manera recursiva. Si queremos
representar la jerarquía de una forma textual, secuencial, en vez
que de forma gráfica, hacemos uso de lo que se llaman
paréntesis, que se abren y que se cierran para representar el
principio y el final de cada elemento jerárquico. Pues bien,
XML no es más que un lenguaje sencillo para representar
información jerárquica o para representar lenguajes de parén-
tesis definidos por el usuario.
3. La familia XML
XML es un
metalenguaje
. Eso quiere decir que XML permite
definir diferentes
lenguajes de marcado
, utilizando DTDs o
Schemas. Un lenguaje de marcado es un lenguaje que permite
añadir marcas o etiquetas que describen el contenido del docu-
mento para dar semántica o indicar la presentación del conteni-
do. Habitualmente, el contenido es textual.
Sin entrar en una descripción detallada de cómo es un
documento XML, conviene introducir los conceptos básicos
que se utilizan. En el caso de XML, las etiquetas empiezan
con el símbolo «<» y terminan con el símbolo «>».
Habitualmente las etiquetas encapsulan un cierto trozo de
contenido, al que están describiendo. En ese caso, la etiqueta
que se coloca inmediatamente antes del contenido que se
desea encapsular se escribe con un nombre rodeado por los
símbolos «<» y «>», por ejemplo
<juez>
. La etiqueta que
se coloca justo después del contenido comienza con «</»,
por ejemplo
</juez>
. El nombre que se escribe en ambas
etiquetas ha de ser el mismo. Por ejemplo:
<juez>Don Francisco Ortega Ortega</juez>
El contenido encapsulado por una pareja de etiquetas puede
contener a su vez otras etiquetas, además de texto:
<juzgado>
<provincia>Madrid</provincia>
<población>Madrid</población>
</juzgado>
A una pareja de etiquetas junto con su contenido se le llama
en terminología XML
elemento
. Puede ocurrir que haya un
elemento que no contenga nada. En ese caso, se puede
sustituir la pareja de etiquetas por una única etiqueta que
termina con «/>», por ejemplo
<absuelto/>
.
Los elementos pueden contener atributos. Un atributo es una
pareja (nombre, valor) que permite dar cierta información
sobre un elemento. Un atributo se escribe dentro de la etiqueta
inicial del elemento, a continuación del nombre de la etiqueta,
utilizando la sintaxis
nombre="valor"
. Por ejemplo:
<juez promoción="1997">
Don Francisco Ortega Ortega
</juez>
Un documento XML correcto debe cumplir una serie de
reglas. Por ejemplo, las etiquetas deben de estar correcta-
mente anidadas. Por lo tanto, el siguiente texto no sería
correcto:
<juzgado>
<provincia>Madrid</juzgado>
</provincia>
Un documento XML que verifica esta regla y otras en las que
no entramos se dice que está «bien formado».
Un DTD permite definir como son los documentos XML
utilizados en un cierto dominio de aplicación. Entre otras
cosas, un DTD permite definir:
- etiquetas que se pueden utilizar;
- contenido de cada elemento, es decir, qué elementos pue-
den formar parte del contenido de una etiqueta y si el
elemento puede contener texto o no;
- atributos de cada elemento, opcionales o obligatorios.

Page 7
NOVATICA/UPGRADE jul./ago. 2002 nº158
10 Edición digital/ ©ATI 2002
El DTD puede formar parte del documento XML, pero lo
normal es que esté en un documento aparte, para que pueda
ser referenciado por los diferentes documentos XML que
utilizan ese DTD.
Cuando un documento XML que está bien formado sigue las
reglas definidas en un DTD (cuál es el DTD que utiliza un
documento XML está indicado en el propio documento), se
dice que el documento XML es «válido».
Existen multitud de aplicaciones en las que se usan los
DTDs. Por ejemplo, existen DTDs que se utilizan en el
campo del periodismo (NewsML, NITF), legales, en comer-
cio electrónico, para integrar herramientas informáticas, y
muchas otras, incluso en aplicaciones de biotecnología.
Los DTDs tienen algunas limitaciones. Por ejemplo, no es
posible definir que el texto encapsulado por una pareja de
etiquetas o el valor de un atributo sea un número. Esto puede
ser interesante en muchas ocasiones, por ejemplo para
definir una fecha, una cantidad, etc.
Otra limitación de los DTDs es en cuanto a lo que se puede
especificar respecto del contenido de un elemento. Por
ejemplo, en un DTD se puede especificar que un elemento
puede contener otro elemento 1 vez, 0 a 1 veces, 0 a varias
veces o 1 a varias veces, pero no es posible definir (al menos
fácilmente) que un elemento ha de contener entre 3 y 15
veces otro elemento.
Esta y otras limitaciones han hecho que se desarrolle un
nuevo estándar, XML
Schema
que permite definir como son
los documentos XML que se utilizan en una cierta aplica-
ción de una forma más precisa que los DTDs.
En ciertas situaciones, puede ser necesario utilizar elementos
definidos en varios DTDs. Por ejemplo, una tienda electrónica
puede utilizar un DTD para las órdenes de compra y otro para
el catálogo de productos. Puede ocurrir que se desee mantener
los dos DTDs separados por varias razones: uso de DTDs
estándar o para separar diferentes partes de la tienda electróni-
ca. Sin embargo, es posible que una orden de compra incluya
información definida en el DTD del catálogo: nombre y código
del producto, precio, etc.
A diferencia de HTML, las etiquetas de un documento XML
no dicen nada sobre cómo se debe de ver el documento en un
navegador, ya que han sido definidas por el usuario. Por lo
tanto, es necesario dotar a XML de mecanismos que permi-
tan definir como presentar un documento XML. Estos
mecanismos son las hojas de estilo XSL y CSS, presentadas
a continuación.
Por otra parte, el hecho de que en un documento XML no se
diga nada acerca de la presentación nos da gran flexibilidad
para decidir como presentarlo. Podemos hacer varias pre-
sentaciones diferentes de un mismo documento XML. Pode-
mos definir como queremos que se vea un documento XML
en diferentes plataformas (navegador Web, teléfono móvil,
papel). Podemos decidir que partes del documento quere-
mos presentar y que partes queremos ocultar.
El lenguaje extensible de hojas de estilo (
eXtensible Stylesheet
Language
, XSL) es una herramienta esencial a la hora de
manipular documentos XML. Por su simplicidad, es el
mecanismo preferido para manipular documentos XML por
personas no expertas en Informática.
XSL permite 1) definir cómo presentar un documento XML
y 2) convertir un documento XML en otro documento en
formato XML, HTML o texto plano (lo que permite conver-
tir a cualquier formato de presentación que se represente en
texto plano, como por ejemplo RTF o
PostScript
).
Ya hemos mencionado anteriormente que una de las venta-
jas de XML es que permite separar la semántica con que se
pretende enriquecer un cierto documento de cómo se presen-
ta el contenido del documento. El mecanismo utilizado de
forma prácticamente universal para describir como presen-
tar un documento XML son las hojas de estilo CSS (que se
presentan más adelante) y las XSL.
Utilizando hojas de estilo XSL es posible convertir un
documento XML a cualquier formato de presentación
(HTML,
PostScript
, PDF, WML para móviles, etc.), lo que
permite presentar un mismo documento XML en diferentes
plataformas: un ordenador con un navegador Web, una
versión imprimible, otra para teléfono móvil, otra para
televisión digital, etc. Naturalmente, es posible disponer de
un conjunto de hojas de estilo que generen versiones en
diferentes formatos de un mismo documento XML e incluso
disponer de varias hojas de estilo para un mismo formato
(por ejemplo para generar varias versiones en HTML del
mismo documento XML).
En muchas ocasiones es necesario realizar un cierto trata-
miento de documentos XML. Si este tratamiento no es
excesivamente complejo, es posible realizarlo utilizando
hojas de estilo XSL. Por ejemplo, imaginemos una tienda
electrónica que recibe de una editorial documentos XML
utilizando un cierto DTD propietario de la editorial que
describen los libros editados por la editorial. La tienda
electrónica a su vez utiliza su propio DTD para describir el
catálogo de productos (que incluye otros productos además
de libros) que ofrece a los clientes. Puede ser muy útil en este
contexto disponer de una hoja de estilo XSL que convierta
los documentos XML enviados por la editorial a otros
documentos XML que se ajusten al DTD utilizado por la
tienda electrónica.
En el campo que nos ocupa, el problema del vaciado se
podría resolver por medio de un atributo de nombre «vaciable»
y valores «si» o «no» que identifiquen las partes del texto
que hay que vaciar. Con una hoja de estilo XSL es posible
generar directamente el documento HTML, PDF, etc al que
se le han eliminado las partes que hay que vaciar.
XSL en realidad está formado por tres estándares:
- XPath: es una notación que permite hacer referencia a
parte de un documento XML, entendiendo que esto puede
querer decir que se hace referencia a varios trozos del
documento XML Por ejemplo, se puede hacer referencia en
XPath a todos los elementos de un documento XML cuya
etiqueta es <magistrado>.
- XSLT (
XSL Transformations):
es un lenguaje que permite
definir transformaciones para convertir un documento
XML en otro documento en formato XML, HTML o texto
plano. Los documentos XSLT son también documentos
XML. Hace uso de XPath.
- XSL-FO (
XSL Formatting Objects
): es una aplicación
XML cuya semántica define como presentar un documento

Page 8
NOVATICA/UPGRADE jul../ago. 2002 nº158
Edición digital/ ©ATI 2002 11
XML que utilice los componentes definidos en XSL-FO.
Permite describir la presentación del documento, definien-
do cosas como áreas dentro del espacio de presentación,
tamaño, posición, color, tipo de letra, etc.
Las hojas de estilo en cascada CSS (
Cascading Style Sheets
)
son una alternativa a XSL para definir como presentar un
documento XML. CSS permite definir como presentar un
documento XML en un navegador u otro dispositivo (por
ejemplo, permite definir como imprimir un documento).
Nótese que en el caso de las hojas de estilo CSS no se obtiene
un nuevo documento (caso de XSL), sino que la propia hoja
de estilo define como presentar cierto documento XML.
La presentación de un documento XML con CSS se basa en
asociar a los elementos del documento XML propiedades
relativas a cómo deben de ser presentados: tipo de letra,
tamaño, fuente, márgenes, etc.
Los espacios de nombres (
Namespaces
) permiten definir un
documento XML que utiliza elementos obtenidos de dife-
rentes fuentes. Para ello, se asocian prefijos al nombre de la
etiqueta de cada elemento y se identifica unívocamente cada
prefijo por medio de una URI (
Uniform Resource Identifier
),
una generalización de las conocidas URLs.
Los dos últimos estándares que vamos a introducir en esta
breve presentación de XML son XLink y XPointer. Estos
dos estándares conjuntamente permiten definir vínculos
entre documentos XML. Juegan el papel de los hiperenlaces
en el mundo HTML, pero son mucho más potentes. El
estándar que permite definir los vínculos es XLink. Distin-
gue entre dos tipos de vínculos. El tipo simple permite que
un cierto recurso de un documento XML apunte a un otro
recurso. Es similar a los hiperenlaces de HTML. Un recurso
se define como una unidad de información o un servicio al
que es posible hacer referencia. Por lo tanto, un documento
XML es un recurso. También es un recurso un cierto
elemento de un documento XML en vez del documento
XML completo.
El tipo extended es la forma más general de definir vínculos.
De hecho, el tipo simple es un caso particular del tipo
extended. Con vínculos de tipo extended es posible definir
vínculos en los que hay varios recursos origen que apuntan
a varios recursos destino (a diferencia del tipo simple en el
que un cierto recurso apunta a otro).
Al definir un vínculo, es necesario especificar cuáles son los
recursos origen y destino involucrados en el vínculo (en los
vínculos de tipo simple solamente hace falta especificar el
recurso destino, ya que el recurso origen es el elemento
donde se define el vínculo). El papel de XPointer es el de
poder identificar un cierto recurso. En realidad, es una
extensión de XPath. En XPath solamente es posible hacer
referencia a elementos o atributos. XPointer permite tam-
bién identificar un cierto punto en el texto que contiene un
elemento XML (con XPath solamente se podría referenciar
el elemento completo).
4. Características de XML
El «Lenguaje Extensible de Marcas» (
eXtensible Markup
Language
) XML responde a la necesidad de disponer de
formatos para describir diferentes tipos de contenidos de
forma electrónica, para poder almacenarlos, procesarlos y
transmitirlos. Sin entrar en aplicaciones específicamente
informáticas, en múltiples campos es necesario disponer de
notaciones que permitan describir contenidos.
Por mencionar un ejemplo, en el campo del periodismo
existen formatos desde finales de los años 70 que permiten
describir noticias. Utilizando estos formatos, junto con el
texto de la noticia, se puede incluir informaciones que no
forman parte estrictamente del texto de la noticia, como por
ejemplo, la fecha, la sección a la que pertenece la noticia o
identificar la parte del texto que constituye el titular.
Estos formatos son utilizados para transmitir las noticias de
la agencia de noticias a un medio de comunicación o para
almacenar las noticias en una base de datos y luego poder
realizar búsquedas eficientes. Los formatos que se desarro-
llaron inicialmente se han quedado obsoletos, y actualmente
se están desarrollando nuevos formatos que utilizan XML.
Las herramientas software utilizan XML cada vez más.
Entre otros, podemos mencionar los siguientes usos de XML
en este ámbito: se usa XML como formato interno en
determinadas herramientas; también se usa para proporcio-
narle al usuario documentación sobre la herramienta, lo que
permite ofrecerle, utilizando hojas de estilo, una versión
HTML para ver con un navegador, una versión PDF para
imprimir e incluso podemos permitirle al usuario acceder
directamente a la documentación en formato XML para
realizar búsquedas sobre datos estructurados; otro uso que
cada vez cobra más importancia es utilizar XML como
formato de intercambio de información entre distintas he-
rramientas informáticas que se desea que puedan interoperar.
XML no es la primera tecnología que se desarrolla con estos
fines, ni será la última. Podemos plantearnos entonces, por
qué utilizar XML en vez de alguna otra de las alternativas
existentes. Entre otras, podemos mencionar las siguientes
ventajas de XML:
XML es potente
. Por medio de los DTDs y los XML
Schemas, es posible definir como se desea que sean los
documentos XML de una aplicación concreta. Es posible
realizar nuevas versiones de cómo se quiere que sean los
documentos (es decir, modificar el DTD o Schema) con un
coste razonable.
XML permite separar los aspectos de descripción del conte-
nido de los aspectos de presentación. En un documento
XML es posible incluir toda la información necesaria para
describir el contenido: estructura del documento, cataloga-
ción del documento completo y de sus partes (metadatos),
definición de documentos relacionados (vínculos), etc. En
un entorno de trabajo basado en XML lo habitual es que el
documento XML describa las informaciones que se desea
añadir al texto del documento (como en el ejemplo de
periodismo presentado anteriormente), pero no incluir as-
pectos de presentación (tipo de letra, tamaño, justificación,
etc.).
Posteriormente, utilizando tecnologías de hojas de estilo, es
posible generar versiones del documento en diferentes
formatos, como por ejemplo, HTML (para la publicación del

Page 9
NOVATICA/UPGRADE jul./ago. 2002 nº158
12 Edición digital/ ©ATI 2002
documento en el Web), texto plano, PDF, etc. El hecho de
que los aspectos de presentación normalmente no están
descritos en un documento XML hace que sea posible
realizar varias versiones del mismo documento en un mismo
formato, pero con distinto aspecto. Por ejemplo, utilizar
diferentes colores para el fondo y la letra de una página
HTML, etc. Pero si se desea, también es posible incluir
aspectos de presentación en un documento XML. En todo
caso si el marcado del documento XML consta exclusiva-
mente de elementos de formato de texto, se debería de
valorar el utilizar otras tecnologías, como por ejemplo
HTML combinado con CSS.
XML es simple
. XML es una simplificación de SGML
(
Standard Generalized Markup Language
). SGML es un
potente formato para describir lenguajes de marcado, pero
no ha tenido demasiado éxito, debido a su complejidad. Por
ello, el W3C decidió desarrollar una versión simplificada de
SGML que mantuviese la mayor parte de su potencia pero
que fuese mucho más simple. El resultado es XML.
XML es un estándar abierto
. XML es un estándar del W3C
(
World Wide Web Consortium
), el organismo que desarrolla
los estándares relacionados con el Web. Alrededor de XML,
el W3C ha desarrollado una familia de estándares que
facilitan el uso de XML. El hecho de que XML sea un
estándar es beneficioso por varias razones. Por un lado
permite el que cualquier desarrollador de software pueda
desarrollar herramientas para él, con lo que usar XML no
nos ata a una compañía concreta. Por otra parte, el proceso
de desarrollo de los estándares del W3C es una garantía de
la calidad de los mismos.
XML es cada vez más ampliamente utilizado
, lo que
favorece su desarrollo: comparación con experiencias pre-
vias, existencia de profesionales expertos en estas tecnolo-
gías, desarrollo de herramientas de todo tipo alrededor de
XML aprovechando la existencia de un mercado creciente
para las mismas. Los campos de aplicación son amplísimos,
todos los que nos podamos imaginar. Es impresionante
cómo muchos colectivos que tenían sus problemas de cómo
representar su información han elegido XML como el
formato en el cual basarse, por ejemplo: automoción, quími-
ca, matemáticas, educación, derecho, publicidad, turismo,
recursos humanos, banca, noticias, etc. Es increíble cómo
esos sectores, tan diversos todos, están apostando por XML.
XML es fácil de implantar
. Es mucho más fácil tratar
documentos con XML que con otros formatos. El uso de los
DTDs y Schemas para definir las aplicaciones XML, junto
con las herramientas disponibles para tratar documentos
XML hace más fácil el desarrollar aplicaciones informáticas
basadas en XML que con otros formatos.
XML no es un formato sólo entendible por los ordenado-
res
. Un documento XML puede ser entendido por un
humano con conocimiento mínimo del lenguaje XML. En
eso se diferencia por ejemplo de EDI, que es un lenguaje
críptico, ya que cuando se definió se trataba de ahorrar bits.
Lenguajes equivalentes de comercio electrónico basados en
XML se pueden interpretar directamente en caso de necesi-
dad por una persona.
5. Conclusión
Repasemos brevemente los objetivos y las motivaciones de
XML. SGML y su sucesor XML originalmente fueron conce-
bidos para definir lenguajes de marcado que permitiesen separar
forma de contenido. En el caso del Web, además no servía un
solo lenguaje concreto como HTML, ya que un solo lenguaje
tendría que satisfacer las necesidades de demasiados colectivos
y excesivos condicionantes como para ser de utilidad. Por eso
era necesario tener un marco ágil que permitiese definir nuevos
lenguajes según se fuesen necesitando.
El éxito de XML, sin embargo, no proviene del objetivo que
esperaban sus diseñadores; no viene porque se haya separa-
do forma y contenido, sino por una razón en la que no habían
pensado, y es que los datos tienen que circular por la red.
Para ello la mejor forma es estructurar esos datos de forma
jerárquica y para representar información jerárquica, XML
es un formalismo perfectamente adaptado. Por tanto aunque
el planteamiento inicial se refiriese a la presentación (y por
tanto es un planteamiento de tipo B2C --
Business-to-
Consumer
), el éxito de XML se encuentra en que es un
formato de intercambio de información estructurada (y este
es un argumento de tipo B2B --
Business-to-Business
).
Finalicemos con una cita de Dan Connolly del consorcio
W3C: «Por sí mismo XML es solamente un simple formato
de texto pero, unido a las formas en que se está utilizando
para compartir información estructurada, es una revolución
que promete incrementar considerablemente la inteligencia
del Web».
XML en sí mismo no es más que un formato de texto muy
simple. Es casi nada, y precisamente por ser casi nada y por
ser tan flexible está suponiendo una revolución de repercu-
siones tan amplias. XML es el ASCII del siglo XXI.
Referencias
[1] SAX Home Page:
<http://www.saxproject.org/>
[2] Wireless Markup Language version 2 Specification. WAP Forum:
<http://www.wapforum.org/what/technical.htm>
[3] Cascading Style Sheets, level 1, Recommendation
, Enero 1999.
World
Wide Web Consortium
: <http://www.w3.org/TR/REC-CSS1>
[4] Cascading Style Sheets, level 2, Recommendation,
Mayo 1998.
World
Wide Web Consortium:
<http://www.w3.org/TR/REC-CSS2>
[5] Extensible Markup Language (XML) 1.0 Recommendation
, Octubre
2000.
World Wide Web Consortium
: <http://www.w3.org/TR/REC-xml>
[6] Extensible Stylesheet Language (XSL) 1.0 Recommendation,
Octubre
2001.
World Wide Web Consortium
: <http://www.w3.org/TR/xsl/>
[7] Namespaces in XML, Recommendation,
Enero 1999.
World Wide Web
Consortium
: <http://www.w3.org/TR/REC-xml-names/>.
[8] HyperText Markup Language Home Page.
World Wide Web Consortium:
<http://www.w3.org/MarkUp/>
[9] The World Wide Web Consortium (W3C) Home Page:
<http://
www.w3.org/>
[10] W3C Document Object Model (DOM).
World Wide Web Consortium:
<http://www.w3.org/DOM/>
[11] XML Linking Language (XLink) Version 1.0, Recommendation,
Junio 2001.
World Wide Web Consortium:
<http://www.w3.org/TR/xlink/>
[12] XML Pointer Language (XPointer) Version 1.0, Candidate
Recommendation,
September 2001: <http://www.w3.org/TR/xptr/>
[13] XML Schema Part 0: Primer, Recommendation,
Mayo 2001.
World
Wide Web Consortium:
<http://www.w3.org/TR/xmlschema-0/>
[14] XML Schema Part 1: Structures, Recommendation,
Mayo 2001.
World Wide Web Consortium:
<http://www.w3.org/TR/xmlschema-1/>
[15] XML Schema Part 2: Data Types, Recommendation,
Mayo 2001.
World Wide Web Consortium:
<http://www.w3.org/TR/xmlschema-2/>
[16] XQuery 1.0: An XML Query Language, Working Draft,
Abril
2002.
World Wide Web Consortium:
<http://www.w3.org/TR/xquery/>

Page 10
NOVATICA/UPGRADE jul../ago. 2002 nº158
Edición digital/ ©ATI 2002 13
MONOGRAFÍA
XML: ¿el ASCII del siglo XXI?
Resumen:
la rápida expansión de XML se puede explicar,
entre otras razones, por la disponibilidad de un conjunto de
productos software que garantizan un uso rentable y eficaz
de este estándar. Examinamos el impacto que ha causado
XML en varias áreas clave del mundo de las aplicaciones
empresariales: las herramientas y plataformas de desarro-
llo, los sistemas de almacenamiento y las infraestructuras
middleware
y de integración intra e inter-empresa. Habla-
mos no solamente de las nuevas capacidades de proceso
incorporadas sobre productos ya existentes: en último
extremo XML abre la necesidad de una nueva familia
dentro del software de base, ligada específicamente al
soporte de dicho estándar.
Palabras clave:
XML, aplicaciones empresariales, indus-
tria del software
1. Introducción
El uso de XML (
eXtensible Markup Languaje
) en todo tipo
de aplicaciones no ha dejado de crecer en los últimos meses,
fiel reflejo de su consolidación en el mundo empresarial.
XML ha cubierto en muy poco tiempo las etapas inevitables
del ciclo de adopción de toda tecnología que, siguiendo el
modelo de la consultora Gartner Group, son la hiperinflacción
de expectativas, la relativa desilusión y, finalmente, la
estabilidad productiva.
Se trata de un éxito derivado de la concurrencia de muy
diversos factores. Entre ellos podemos mencionar las bon-
dades intrínsecas del estándar como tal o la existencia de
numerosos acuerdos de naturaleza empresarial para com-
partir vocabularios e intercambiar documentos electrónicos
basados en XML.
En este artículo me quiero centrar en otro de los factores
cruciales que explican este proceso de consolidación: la
disponibilidad de una amplia oferta de productos y platafor-
mas software que cada vez hacen más productiva y maneja-
ble la implementación de aplicaciones basadas en XML.
Por un lado, el «fenómeno» XML ha alterado la evolución
de nuestras herramientas e infraestructuras tradicionales de
desarrollo (por ejemplo, con la inclusión de
parsers
XML y
motores de hojas de estilo XSLT en la mayor parte de
servidores de aplicaciones). Por otro lado, ha propiciado la
aparición de nuevas familias de productos software (por
XML, el desarrollo de nuevas
aplicaciones empresariales y
la industria del software
Enrique Bertrand López de Roda
Director de Tecnología, Software AG España.
<ebertrand@softwareag.es>
Autor
Enrique Bertrand López de Roda
es Director de Tecnología
en Software AG España, empresa en la que trabaja desde
1986. Es licenciado en Ciencias Químicas por la Universidad de
Valencia. Empezó su trayectoria profesional en ERIA y en sus
20 años de experiencia ha participado como ingeniero de
software, jefe de proyecto y consultor en el diseño y construc-
ción de numerosos sistemas informáticos. En la actualidad su
actividad principal se centra en el desarrollo de soluciones de
integración y servicios electrónicos, con particular énfasis en las
arquitecturas basadas en el estándar XML. Ha sido durante
varios años profesor asociado en el Departamento de Ingenie-
ría Informática de la Universidad Autónoma de Madrid.
ejemplo, las llamadas bases de datos nativas XML o los
editores de
schemas
y hojas de estilo XSLT --
XSL
Transformations
). De todo ello damos cuenta en los siguien-
tes apartados.
2. El valor de XML en el desarrollo de
aplicaciones: software XML
Cuando, hoy por hoy, hablamos de aplicaciones basadas en
XML nos estamos refiriendo en realidad a cualquier tipo de
sistema informático empresarial que hace uso, de una u otra
manera, con mayor o menor extensión, de las ventajas
derivadas del estándar. El compromiso de la mayor parte de
los fabricantes de software revela que XML se ha convertido
en un catalizador tecnológico que, con una metáfora quími-
ca, muchas veces no aparece de forma expresa en la «reac-
ción», aunque sin su presencia el resultado no hubiera sido
posible en un tiempo y a un coste aceptable.
La especificación de XML va acompañada de una cohorte de
subestandáres (XSLT, XPath, DOM, XQuery, etc.) que son
tan importantes o más que el núcleo desde la perspectiva de
un desarrollador. En conjunto, nos proporcionan una base
razonable para construir sistemas más interoperables y más
fáciles de adaptar y mantener en un mundo internet. No es
la panacea universal --ya sabemos que tal cosa no existe en
el ámbito de la Ingeniería del Software-- pero sí es un buen
punto de partida.
¿Por qué utilizamos esencialmente XML? Porque, hoy por
hoy, cualquier documento electrónico expresado de esta
manera es más fácil de definir, validar, procesar y transfor-
mar que si estuviese en cualquier otro formato. Pero a veces
nos olvidamos que estas ventajas no están tanto en XML,

Page 11
NOVATICA/UPGRADE jul./ago. 2002 nº158
14 Edición digital/ ©ATI 2002
que a fin de cuentas es
sólo
un (meta)lenguaje de naturaleza
descriptiva, como en la existencia de componentes software
que son los que realmente simplifican el trabajo desde
nuestras aplicaciones.
De acuerdo con los presupuestos de partida de XML, hoy
disponemos de una amplísima oferta de estos componentes
en cualquiera de los lenguajes de programación utilizados
habitualmente (Java, VB, C/C++, JavaScript, Perl, Cobol,
Natural, etc), y sobre cualquiera de los sistemas operativos
presentes en el mundo empresarial (OS/390, Unix, Linux,
Windows, etc.).
Si tuviéramos que quedarnos únicamente con los dos ingre-
dientes ineludibles para desarrollar aplicaciones XML ten-
dríamos:
- Un procesador XML o
parser
, que procesa un documento
XML, verificando el cumplimiento (si es el caso) de las
restricciones expresadas en el correspondiente
schema
y
exponiendo a los programas una conjunto de APIs
estandarizadas (DOM, SAX, JDOM) que permiten mani-
pular/extraer su contenido.
- Un motor de transformación XSLT o procesador de hojas
de estilo, que permite aplicar sobre un documento XML un
documento XSLT u hoja de estilo, obteniendo como resul-
tado un documento en cualquiera de los posible formatos
de salida (XML, texto plano, HTML, WML, etc.).
La tendencia en cualquier caso es a incorporar estas funcio-
nes básicas y otras similares en los entornos de desarrollo de
aplicaciones integrados (IDEs) de la mayor parte de fabri-
cantes de software de base: IBM, Sun, Microsoft, Oracle,
Software AG, etc. También podemos observar que los
proveedores más significativos de soluciones de gestión y
planificación empresarial como SAP o Siebel disponen en
las últimas versiones de sus productos de interfaces embebi-
das para emitir/recibir documentos XML.
3. El impacto de XML en las herramientas,
plataformas y productos de software de base
Que casi todos los entornos de desarrollo o soluciones
empresariales hayan asumido la capacidad para generar y
procesar documentos XML en relativamente poco tiempo ha
sido un primer paso en la dirección adecuada, necesario,
pero no suficiente.
Cuando consideramos el tipo de aplicaciones en las que
resulta valioso el uso de XML surgen nuevas demandas en
términos de infraestructura y herramientas de apoyo. Para
entender estas exigencias conviene repasar en qué terrenos
podemos hablar con mayor propiedad de aplicaciones XML.
En general, XML tiene más sentido en un sistema cuanto
más dependiente sea éste de un concepto integral de docu-
mento electrónico complejo y desligado de toda considera-
ción respecto a la plataforma, tanto desde el punto del que
lo produce como del que lo consume. No está de más
recordar aquí que esto también significa que hay aplicacio-
nes en las que no tiene ningún sentido utilizar XML.
Por eso las aplicaciones de gestión de contenidos con acceso
multidispositivo (portales empresariales, sistemas docu-
mentales, etc.) y las aplicaciones de integración e intercam-
bio de información entre empresas (sistemas B2Bi,
marketplaces
, etc) son las más beneficiadas hasta ahora con
la aparición en escena de XML. Sin embargo, no deja de ser
un conjunto muy reducido de usos si lo contemplamos a la
luz del nuevo modelo de desarrollo de aplicaciones conocido
como
web services
.
Como es bien sabido, el modelo
web services
plantea una
nueva arquitectura informática apoyada en tres ideas bási-
cas: en primer lugar, las funciones y procesos de negocio de
una empresa se encapsulan en forma de componentes llama-
dos servicios que ofrecen hacia el exterior de la compañía
una interfaz simple y perfectamente definida; en segundo
lugar, estos servicios se ejecutan en un contexto que permite
el acceso a través de protocolos web (HTTP fundamental-
mente, pero también SMTP o FTP); y por último, y esto es
lo importante para nuestra discusión, los servicios se descri-
ben, localizan, invocan y responden en forma de documen-
tos XML (de acuerdo con los protocolos y estándares SOAP,
WSDL, UDDI, etc.).
Quizás en el futuro buena parte de las aplicaciones críticas
de una compañía sean
web services
, es decir, aplicaciones
XML en el sentido más estricto. Es evidente que para
garantizar la productividad, viabilidad, escalabilidad, fiabi-
lidad, seguridad, etc. de todos estos sistemas y de los que
antes mencionamos necesitamos, en lo que concierne a
XML, algo más que un entorno de desarrollo con un
parser
.
Dos ejemplos claros de los primeros resultados en esta línea:
- La emergencia de un nuevo tipo de herramientas que
podríamos llamar XML IDEs y que incluyen editores de
schemas
, editores de documentos XML y editores de hojas
de estilo XSLT, de manera integrada y con las correspon-
dientes utilidades de pruebas, evaluación de expresiones
XPath, control de versiones, etc.
- La aparición de plataformas tecnológicas globales de
desarrollo/explotación de aplicaciones Internet como son
.NET de Microsoft o SunONE de Sun enteramente susten-
tadas y apoyadas en XML y el modelo de
web services
. Este
modelo es precisamente su único nexo de unión: diferentes
lenguajes, sistemas operativos, estándares de desarrollo,
pero el mismo compromiso con XML.
Otros resultados no tan evidentes y conocidos como los
anteriores surgen como resultado de exigencias ineludibles
para una implementación asumible, robusta y fiable de las
aplicaciones XML. También aquí podemos detectar pro-
puestas claras de nuevos tipos de software o la adaptación de
los existentes:
- La capacidad para almacenar y publicar gran cantidad de
documentos XML con estructuras complejas y/o mutables,
que afecta especialmente a las estrategias de los fabricantes
de gestores de bases de datos.
- La facilidad para integrar los sistemas corporativos here-
dados (
legacy
), que no contemplaban obviamente el uso de
XML, con este nuevo tipo de aplicaciones. En este caso hay
una incidencia directa sobre el mercado de productos
middleware
y de integración.
Veamos con más detalle el impacto que ha supuesto el
estándar XML en cada una de estas dos áreas: sistemas de

Page 12
NOVATICA/UPGRADE jul../ago. 2002 nº158
Edición digital/ ©ATI 2002 15
almacenamiento y publicación e infraestructuras
middleware
y de integración.
4. El almacenamiento y publicación de
documentos XML
Todo el debate actual acerca de las opciones de las que
disponemos para almacenar documentos XML surge de una
cuestión de fondo: ¿realmente es necesario conservar los
documentos XML que recibimos o publicamos?
Si consideramos un documento XML única y exclusivamen-
te como un soporte temporal para facilitar el intercambio de
información entre sistemas, que puede siempre ser construi-
do (o descompuesto) de forma dinámica a partir de los datos
corporativos de la compañía, la respuesta a la pregunta
anterior es no. Por el contrario, la respuesta es afirmativa si
consideramos un documento XML como un elemento
informático del negocio con entidad propia, que conviene
guardar (por ejemplo, por razones legales y de auditoría).
Descartada la posibilidad más inmediata y rudimentaria --
conservar los documentos XML como elementos individuales
en un sistema de ficheros- por razones de escalabilidad,
facilidad de búsqueda, seguridad, etc. los fabricantes de soft-
ware nos ofrecen esencialmente dos alternativas: utilizar un
gestor de bases de datos relacional (RDBMS) con extensiones
que ofrecen una «visión» XML de los datos que almacenan; o
utilizar una nueva familia de gestores que se conocen genéri-
camente como «nativos» XML (XDBMS o NXD).
Los defensores de la opción RDBMS con extensiones argu-
yen que en realidad la mayor parte de los datos críticos de
una compañía residen en este tipo de productos. Nada más
fácil entonces que incluir un conversor automático XML/
relacional de manera que cuando alguien solicita un docu-
mento XML, éste se construye en vuelo a partir de todas las
tablas donde se encuentran los datos necesarios. En la
situación contraria, almacenamiento, se realiza el proceso
inverso, descomposición a tablas (
mapping
).
Cuando hablamos de documentos XML muy simples no
cabe duda de que ésta puede ser una buena opción. Pero en
realidad la naturaleza de un documento XML, una jerarquía
anidada y ordenada de elementos que puede o no tener un
esquema formal detrás, contrasta fuertemente con la visión
tabular, no ordenada y perfectamente determinada de los
datos en un gestor RDBMS.
Con un documento complejo XML, es decir, del tipo que
manejan las aplicaciones del mundo real, este mecanismo de
«enmascaramiento» muestra sus limitaciones: no es tan
transparente para el desarrollador, que debe ayudar al
conversor supuestamente automático a configurar por ejem-
plo las múltiples operaciones de JOIN subyacentes; y puede
suponer una carga de trabajo adicional para los administra-
dores si quieren garantizar el rendimiento del sistema:
detrás de una simple operación de recuperación o almacena-
miento de un documento XML se puede estar accediendo
literalmente a decenas de tablas, algunas de ellas creadas ex
profeso para soportar aspectos de la conversión.
En cualquier caso el problema a largo plazo más severo que
supone esta opción es la pérdida de la integridad del
documento. En numerosas ocasiones existe un requerimien-
to legal que determina que la empresa emisora o receptora
del documento XML debe conservar un ejemplar del mismo,
en particular, en el mundo de las aplicaciones de integración
empresa-empresa (B2Bi). La popularización del modelo
web services
para realizar transacciones comerciales con
implicaciones legales no hará sino reforzar esta demanda.
Para estos casos los RDBMS con extensiones cambian el
enfoque y en lugar del
mapping
sobre tablas optan por
conservar el documento como un bloque en un tipo de
columna especial que soporta objetos binarios o basados en
caracteres grandes (BLOB o CLOB). El precio a pagar es
una reducción severa de las posibilidades de recuperación
ulterior que permite una concepción puramente XML.
En este escenario es donde cobra sentido la segunda opción
propuesta por algunos fabricantes de software (y entre ellos
Software AG): los gestores «nativos» XML o XDBMS.
Dado el «ruido terminológico» medio que sufrimos en
cualquier actividad relacionada con las tecnologías de la
información no existe una definición precisa de lo que debe
entenderse por un gestor nativo XML, pero sí un cierto
consenso en torno a algunas características:
- Los documentos XML cualquiera que sea su naturaleza
(con o sin
schema
) se almacenan tal cual, sin ninguna
manipulación o transformación explícita de su estructura.
La unidad fundamental de almacenamiento desde el punto
de vista lógico es el documento y no los elementos que
contiene.
- Cuando se recupera un documento XML, el resultado es
idéntico a lo que se envió al gestor para almacenar. Es decir,
desde el punto de vista de la aplicación se garantiza la
integridad en contenido y estructura de cualquier documento.
- Las colecciones de documentos son definidas, mantenidas
y accedidas utilizando los correspondientes estándares
XML W3C: XML Schema, XPath, DOM, XSLT, etc.
La ventaja fundamental de los XDBMS es la capacidad para
almacenar y gestionar documentos XML complejos y muy
variables en estructura de una manera íntegra y absoluta-
mente transparente para los desarrolladores. Algunos gesto-
res incluyen además motores de indexación que son muy
eficaces en la búsqueda y recuperación total o parcial de los
documentos, explotando todo el poder «contextual» que
ofrecen las etiquetas XML y las expresiones XPath.
También podemos hablar con propiedad de otra categoría de
software relacionada, los «servidores XML», en la medida
en que ciertos productos XDBMS añaden a sus funciones
básicas de almacenamiento y recuperación de documentos
XML otras muy interesantes: la posibilidad de guardar
objetos binarios; la posibilidad de mostrar los resultados
después de aplicar dinámicamente documentos XSLT; di-
versas pasarelas para acceder en línea a RDBMS o sistemas
de ficheros externos y combinar estos datos con los docu-
mentos que se conservan en el gestor; o la posibilidad de
desarrollar extensiones con nuevas funcionalidades.

Page 13
NOVATICA/UPGRADE jul./ago. 2002 nº158
16 Edición digital/ ©ATI 2002
Las indudables ventajas en determinadas aplicaciones XML
de los XDBMS no significan en modo alguno la sustitución
progresiva de los actuales RDBMS, de la misma manera que
la expansión de XML no implica el abandono del modelo
relacional. Pero también la proposición inversa es cierta: el
modelo relacional y los RDBMS no pueden entrar en
terrenos donde XML y los XDBMS son insustituibles.
Hablamos de dos enfoques distintos y necesarios, datos y
documentos, que se apoyan en soluciones tecnológicas
distintas y necesarias. Y buena prueba de ello son los
recientes anuncios de Microsoft, IBM y Oracle respecto a
futuros gestores nativos XML de estos fabricantes.
5. El papel de las Infraestructuras
middleware
y
de integración en aplicaciones XML
Comunicarse con otras empresas utilizando documentos
XML no siempre es fácil si tenemos en cuenta que la mayor
parte de las aplicaciones existentes en una compañía son
incapaces de generar o entender este tipo de documentos.
Las representaciones de datos que manejan pueden estar
además muy alejadas de lo que figura en los documentos
XML finales.
Un ejemplo típico de esta situación se da en los
web services
que encapsulan el acceso a módulos existentes, quizás
invocables únicamente con una llamada de tipo RPC. Tene-
mos que convertir el documento XML recibido en una
llamada comprensible por el módulo y debemos convertir su
respuesta (típicamente un área de datos) en un documento
XML saliente.
La forma histórica de resolver los problemas de
interoperabilidad entre componentes software escritos en
diferentes lenguajes, adheridos a diferentes estándares y que
se ejecutan en distintos sistemas operativos se ha basado y
se sigue basando en el uso de productos
middleware
. Son
herramientas que enmascaran al desarrollador, a partir de
una interfaz de programación (API) común, las transforma-
ciones y conversiones necesarias para que dos componentes
se puedan comunicar.
No es extraño que los fabricantes de productos
middleware
hayan reaccionado a las demandas antes comentadas incor-
porando nuevas capacidades ligadas a XML como, por
ejemplo, las siguientes:
- Funciones de transformación para trasladar un mensaje
XML a un formato comprensible por la aplicación destina-
taria, o viceversa.
- Funciones de
wrapping
para generar llamadas a módulos
en cualquier lenguaje a partir de documentos XML.
- Funciones de extracción/agregación/fragmentación para
construir documentos XML dinámicamente a partir de
diferentes fuentes de datos tradicionales.
Como en el caso del almacenamiento, también se da el
fenómeno paralelo de nuevos tipos de plataformas
middleware
, en especial aquellas que surgen para controlar
y organizar los intercambios entre empresas (conocidas por
ello como servidores de integración B2B). Estos servidores
simplifican y sistematizan las tareas repetitivas de valida-
ción, transformación, distribución, entrega, etc. de los docu-
mentos XML recibidos o emitidos en el curso de una
transacción comercial. Suelen además integrarse con los
sistemas de almacenamiento nativo XML para todo lo que
tiene que ver con la garantía de persistencia de los documen-
tos y su registro por razones legales.
Frente al reclamo de que XML y los
web services
suponen
la desaparición por innecesarios de los productos
middleware
,
la realidad es bien diferente: utilizar XML en una empresa
que ya dispone de un conjunto de aplicaciones corporativas
sólo es técnica y económicamente posible con el apoyo de
este tipo de productos.
6. Conclusiones
La adaptación del software de base existente y la aparición
de nuevas familias de productos dirigidos a soportar de una
manera más eficaz y productiva el estándar XML es al
mismo tiempo una muestra de su consolidación y una de las
razones esenciales de su rápida difusión.
La influencia de XML es ya perfectamente palpable en un
vasto terreno de plataformas, herramientas e infraestructuras,
que convergen hacia una nueva arquitectura para los siste-
mas informáticos del futuro apoyada en el modelo de «web
services».
Es sin duda una buena noticia para el mundo de XML,
porque no hay iniciativa de estandarización que pueda
prosperar a medio plazo sin una oferta apropiada, por parte
de los fabricantes, de soluciones software que la avalen y
hagan viable.

Page 14
NOVATICA/UPGRADE jul../ago. 2002 nº158
Edición digital/ ©ATI 2002 17
MONOGRAFÍA
XML: ¿el ASCII del siglo XXI?
Resumen:
este artículo presenta una aproximación al desa-
rrollo de aplicaciones mediante el uso de tecnologías XML.
De acuerdo con esta aproximación, las aplicaciones se
describen utilizando lenguajes de marcas XML específicos
del dominio. De esta forma, las aplicaciones quedan descri-
tas por un conjunto de documentos XML que, posteriormen-
te, se procesan para generar la aplicación ejecutable. Así
mismo, la aproximación establece explícitamente la separa-
ción entre documentos de contenidos y documentos de des-
cripción de otros aspectos de la aplicación (p. ej., interacción,
presentación y proceso), lo que simplifica el mantenimiento
y aumenta la reutilización, tanto del software de procesa-
miento de los lenguajes de marcas involucrados como de los
propios documentos marcados. El artículo describe nues-
tras experiencias con esta aproximación, a través de su
aplicación al dominio de los hipermedia y su posterior
generalización a un marco de desarrollo para soportar un
rango más amplio de aplicaciones basadas en contenidos.
Palabras clave:
lenguajes de marcas, lenguajes específicos
del dominio, desarrollo de software, hipermedia, modelo
de procesamiento XML, XML.
1. Introducción
XML (
eXtensible Markup Language
) [16] es un lenguaje
para definir
lenguajes de marcado
(es por tanto un
metalenguaje), que junto con un conjunto de reglas que
rigen cómo añadir marcado a un texto, permite construir
documentos
en los que se hace explícita la estructura de los
mismos. Los
lenguajes de marcado descriptivos
permiten,
además, establecer la estructura lógica de los documentos de
forma independiente a su procesamiento. En los lenguajes
definidos con XML, dicha estructura se concibe como un
árbol de
elementos
, donde cada elemento puede tener aso-
ciado un conjunto de pares
atributo ­ valor
. XML permite
definir dichas estructuras utilizando un formalismo grama-
tical (p. ej., DTD --
Document Type Definition
, XML
Schema
[22],etc. ). En principio, el marcado XML
no
expresa cómo
procesar un documento concreto. Dicho proceso debe ser
añadido
posteriormente mediante programas que
interpre-
ten
adecuadamente dicho marcado.
El dominio inicial de los lenguajes de marcado descriptivo
fueron aplicaciones que tenían como objetivo organizar y
procesar
grandes volúmenes
de documentos de forma flexi-
ble. Requisitos esenciales de este tipo de aplicaciones eran:
Aplicación de los Lenguajes de
Marcado XML en el Desarrollo
de Software
Este trabajo ha sido financiado parcialmente por la Comisión
Interministerial de Ciencia y Tecnología (CICYT) mediante los
proyectos TIC2000-0737-C03-01 y TIC2001-1462
Baltasar Fernández-Manjón, Alfredo Fernández-
Valmayor, Antonio Navarro, José Luis Sierra
Grupo de Investigación en Ingeniería del Software e
Inteligencia Artificial, Depto. de Sistemas Informáticos y
Programación, Facultad de Informática, Universidad
Complutense de Madrid
<{balta, alfredo, anavarro, jlsierra}@sip.ucm.es>
Autores
Baltasar Fernández Manjón
es Licenciado y Doctor en Cien-
cias Físicas, y Profesor Titular de Universidad en el Departa-
mento SIP de la UCM. Sus intereses investigadores principales
se centran en la aplicación de las tecnologías de marcado en el
dominio educativo, el uso de estándares educativos y el mode-
lado de usuarios.
Alfredo Fernández-Valmayor
es Licenciado y Doctor en
Ciencias Físicas, y Profesor Titular de Universidad en el Depar-
tamento SIP de la UCM. Sus principales líneas de investigación
son el uso educacional de los lenguajes de marcado, así como
el desarrollo y autoría en sistemas educativos sobre WWW.
Antonio Navarro
es Licenciado en Ciencias Matemáticas y
Profesor Asociado en el Departamento SIP de la UCM. Acaba
de finalizar una tesis doctoral sobre la conceptualización, proce-
so y prototipado de aplicaciones hipermedia. Sus principales
intereses investigadores son el desarrollo e ingeniería de aplica-
ciones hipermedia.
José Luis Sierra
es Licenciado en Informática y Profesor
Asociado en el Departamento SIP de la UCM. Actualmente esta
realizando una tesis doctoral sobre la adición de semántica
operacional a lenguajes de marcas y su aplicación en el desa-
rrollo de Software. Sus principales intereses investigadores se
centran en el procesamiento de lenguajes de marcado y su uso
en la construcción de aplicaciones mediante lenguajes especí-
ficos del dominio.
ofrecer la posibilidad de estructurar la información de
manera unívoca, facilitar el mantenimiento de estas estruc-
turas en el tiempo, garantizar la no dependencia respecto del
sistema y finalmente la independencia de la información
con respecto a su presentación/procesamiento final. SGML
(
Standard Generalized Markup Language
) [4], el lenguaje
de marcado generalizado estándar predecesor de XML, fue
formulado para estandarizar este tipo de lenguajes
1
en
determinados dominios de aplicación (p. ej., aviónica o
sistemas de defensa).
No obstante, pronto se demostró que este tipo de tecnologías
de marcado era aplicable a otros dominios y surgieron
nuevos estándares en este sentido. El más significativo,
HyTime [8], es una extensión SGML para la descripción de
aplicaciones hipermedia, que pone de manifiesto que es
posible utilizar documentos marcados para describir aplica-
ciones de complejidad no trivial.
Por otra parte, DSSSL (
Document Style Semantics and
Specification Language
) [7] muestra cómo es posible des-
cribir el procesamiento de un determinado tipo de documen-
tos marcados mediante un conjunto de reglas de transforma-

Page 15
NOVATICA/UPGRADE jul./ago. 2002 nº158
18 Edición digital/ ©ATI 2002
DSL
de contenidos
Documentos XML de
contenidos: recoge los
contenidos de la aplicación
DSL
de la aplicación
Documento XML de la
aplicación: describe el
significado
de los contenidos
DSL
de interrelación
Documentos XML que
describe la interrelación
entre los contenidos y la
descripción de la aplicación
Procesador
Aplicación
Figura 1. Uso de XML para realizar una aproximación basada en DSLs
al desarrollo de software
ción aplicables a estos documentos. Tales iniciativas se han
trasladado al mundo XML. El análogo a
HyTime
se encuen-
tra diseminado en propuestas como SMIL (
Synchronized
Multimedia Integration Language
) [18], una aplicación
2
XML para la descripción de presentaciones multimediales
o XLink/Xpointer [19][21], un conjunto de patrones XML
para la descripción de hiperenlaces/posiciones entre/en
documentos. Por su parte, DSSSL se materializa en XSL
(
eXtensible Stylesheet Language
)
3
[17][20][23], que per-
mite, entre otras cosas, describir hojas de estilo (reglas de
transformación) para documentos XML, esta vez utilizando
exclusivamente sintaxis XML.
Nuestro interés por los lenguajes de marcado surgió a raíz de
las limitaciones expresivas de HTML (
eXtensible Markup
Language
) para la caracterización de diversas aplicaciones
hipermedia educativas desarrolladas en el seno de nuestro
grupo de investigación en los años noventa [3].
Tomando como referencia las ideas del modelo Dexter [5]
propusimos una caracterización de las aplicaciones
hipermedia basada en la separación de la descripción de los
contenidos y su estructura, respecto del esquema navegacional
y la presentación de la aplicación (interfaz de usuario y
relaciones navegacionales entre los elementos de la interfaz).
La representación de ambos aspectos de las aplicaciones
hipermedia se realizaba mediante dos DTDs SGML. La
primera, específica en cada caso, servía para la caracteriza-
ción de los contenidos y su estructura (la
DTD de conteni-
dos
). La segunda, genérica para cada familia de aplicaciones
hipermedia, servía para la caracterización del esquema
navegacional (la
DTD de la aplicación
).
En la actualidad, esta idea ha evolucionado y se ha conver-
tido en una aproximación al desarrollo de aplicaciones
basada en el uso de lenguajes de marcado y tecnologías
XML. Las aplicaciones susceptibles a ser desarrolladas
mediante esta aproximación se describen a muy alto nivel
como documentos XML, que, posteriormente, se procesan
para dar lugar a la aplicación ejecutable. En este artículo
describimos brevemente nuestra experiencia en el desarro-
llo de esta aproximación, primero mediante su aplicación al
dominio de los hipermedia, y después mediante su genera-
lización a un marco de desarrollo capaz de tratar con un
espectro más amplio de aplicaciones.
2. Desarrollo de aplicaciones mediante
lenguajes de marcado específicos del
dominio
El uso de lenguajes de marcado descriptivo para
describir aplicaciones puede considerarse como
un caso particular de la aproximación al desarrollo
de
software
basada en
lenguajes específicos del
dominio
(DSLs --
Domain Specific Languages
)
[2].
Un DSL es un lenguaje especializado en la des-
cripción de un determinado tipo de aplicaciones.
Los DSLs permiten, al mismo tiempo, un alto grado de
abstracción junto con una descripción adecuada al dominio
del problema, lo que debe facilitar el desarrollo de aplicacio-
nes (si los lenguajes definidos aciertan a capturar los elemen-
tos fundamentales del dominio de aplicación).
En la actualidad, nosotros utilizamos las tecnologías XML
como el núcleo de una aproximación al desarrollo de apli-
caciones basada en la utilización de DSLs expresados me-
diante lenguajes de marcas para describir diferentes aspec-
tos del dominio y de las aplicaciones. Para ello, tras una
primera fase de
análisis del dominio
, obtenemos los siguien-
tes productos:
- Uno o varios DSLs de
contenidos
para representar la
estructura de los
contenidos
de la aplicación.
- Un DSL de la
aplicación
para describir declarativamente
los aspectos más relevantes de la presentación, interacción
y proceso de la aplicación.
- Un DSL de
interrelación
que permite relacionar los
contenidos con la descripción de la aplicación. El uso de
XML para la definición de los DSLs de contenidos y de la
aplicación permite aplicar lenguajes estándar (como XPath
[20] o XSLT [23]) como DSLs de interrelación.
La construcción de una aplicación particular (
figura 1
) supone
proporcionar los documentos XML concretos conformes con
cada uno de estos DSLs. Dicha documentación es, posterior-
mente, procesada para obtener la aplicación ejecutable.
3. Desarrollo de aplicaciones hipermedia: Pipe y
GAP
Hasta ahora, el principal dominio de aplicación de nuestra
aproximación ha sido el de la creación de hipermedias
(como se describe mas ampliamente en [12]). Partiendo de
los modelos hipermedia clásicos, complementados por un
análisis del dominio (especialmente de los hipermedias
educativos), hemos proporcionado una caracterización de
alto nivel de las aplicaciones hipermedia mediante un
modelo abstracto: el modelo
Pipe
. Este
modelo hipermedia
esquema navegacional
y permite caracterizar la interfaz de
usuario y las relaciones navegacionales existentes entre los
elementos de dicha interfaz. El tercero está compuesto por
las
funciones de canalización
, las cuáles nos permiten
relacionar el grafo de contenidos y el esquema navegacional.
De crucial importancia es la
canalización
(o
interpreta-
ción
) de los enlaces definidos entre nodos de contenidos, a
través de los enlaces definidos a nivel navegacional (
pipes
).

Page 16
NOVATICA/UPGRADE jul../ago. 2002 nº158
Edición digital/ ©ATI 2002 19
En cuarto lugar tenemos la
semántica de navegación
que
caracteriza la respuesta de la aplicación hipermedia a la
selección de un enlace. Finalmente la
semántica de presenta-
ción
describe características específicas de estilo, tales como
tamaño de las fuentes, color, etc.
Una vez que se tiene una representación de la aplicación a
través del modelo Pipe, se utilizan dos DTDs XML, que,
guiadas por dichas representaciones Pipe, sirven para la
construcción de prototipos de la aplicación final. La
DTD de
contenidos
es específica para cada aplicación, y sirve para
estructurar los contenidos y enlaces entre estos. La
DTD de
la aplicación
puede ser común a un determinado tipo de
aplicaciones, y sirve para capturar el esquema navegacional
y sus relaciones con los contenidos. La relación entre ambas
instancias de estas DTDs (
documento de contenidos
y
documento de la aplicación
respectivamente) se lleva a cabo
mediante la técnica de
sobremarcado
. Esta técnica consiste
en utilizar expresiones XPath en el documento de la aplica-
ción para seleccionar los contenidos que deberán aparecer
en los componentes de la interfaz gráfica, y es una evolución
de la técnica presentada en [10]. Obsérvese que, aquí, el DSL
de contenidos viene dado por la DTD de contenidos, mien-
tras que el DSL de la aplicación viene dado por la DTD de
la aplicación. Por último, XPath juega el papel del DSL de
interrelación.
Utilizando estas descripciones de la aplicación hipermedia,
un programa Java denominado
GAP
(Generador Automáti-
co de Prototipos) produce prototipos de la versión final de la
aplicación. En nuestra aproximación actual no generamos
aplicaciones finales, ya que, en principio, estas técnicas de
construcción de hipermedias las hemos restringido a las
fases de conceptualización y prototipado [11]. En la actua-
lidad estamos estudiando la ampliación de esta etapa a la de
generación de aplicaciones, con una filosofía similar a la del
modelo Amsterdam [6] y el lenguaje SMIL. La
figura 2
muestra cómo funciona dicho GAP. La
figura 3
recoge un
documento de la aplicación y el prototipo generado.
4. Un marco genérico para el desarrollo de
aplicaciones: DTC
Paralelamente a la utilización de nuestra aproximación en
el dominio hipermedia, estamos construyendo un marco de
aplicación de nuestra aproximación (descrita en la
figura 1
)
capaz de tratar con un tipo más amplio de aplica-
ciones. Para ello, en vez de basarnos en un modelo
específico para un tipo de aplicaciones, como
hacíamos en el caso anterior con
Pipe
, nos centra-
mos en el papel que juegan los lenguajes de mar-
cado en la definición de los DSLs y en el problema
de dotar de semántica operacional a dichos lengua-
jes [13][14]. A este nuevo enfoque lo hemos deno-
minado DTC (Documentos estructu-rados, Trans-
formaciones documentales y Componentes
soft-
ware
).
En DTC utilizamos XSLT (
XSL Transformations
)
como lenguaje de interrelación. Por otra parte,
DTC asocia un
componente software
con cada tipo de ele-
mento en el DSL de la aplicación. La construcción de una
aplicación DTC supone proporcionar:
a)
los documentos de
contenidos,
b)
las transformaciones XSLT para generar parte
de la descripción de la aplicación a partir de dichos conteni-
dos, y
c)
el resto de la descripción de la aplicación que no es
generable en el proceso de transformación.
Con todos estos elementos, y aplicando las transformaciones
XSLT, es posible generar un único documento, a partir del
cuál se obtiene la aplicación ejecutable. Para ello, primero se
obtiene el árbol DOM (
Document Object Model
) [15] de
dicho documento, utilizando un
parser
XML estándar.
Dicho árbol es, entonces, procesado por un
intérprete exten-
sible
que, utilizando los
componentes software
asociados
con cada tipo de elemento,
ensambla
la aplicación como un
agregado de objetos que, posteriormente, puede activarse
para lograr la ejecución de la misma. Este funcionamiento
se ajusta a una técnica bien conocida de construcción de
intérpretes denominada de
análisis y evaluación
[1]. La fase
de
análisis
se corresponde con el ensamblaje de la aplica-
ción, mientras que la fase de
evaluación
se corresponde con
la ejecución de la misma. La
figura 4
esquematiza este
proceso.
El DSL de la aplicación se formula, en DTC, combinando
lenguajes más simples (en última instancia, añadiendo
nuevos tipos de elementos), y se instrumenta asociando
componentes con cada tipo de elemento. Para posibilitar la
combinación incluimos la posibilidad de
adaptar
compo-
nentes mediante la aplicación de
adaptadores
. El mecanis-
mo resultante es, en cierta forma, equivalente a técnicas de
construcción modular de intérpretes, como las descritas en
[9].
Actualmente estamos trabajando para proporcionar una
caracterización más precisa del tipo de aplicaciones para las
que DTC puede resultar ventajoso, así como de las herra-
mientas CASE necesarias para facilitar su aplicación. La
figura 5
esquematiza el uso de DTC en la instrumentación
de una aplicación de búsqueda de caminos mínimos en redes
de metro.
Los DSLs de contenidos permiten describir la estructura de
la red de metro, junto con información temporal e informa-
ción geométrica (utilizada para la presentación gráfica de la
Figura 2. Esquema de funcionamiento GAP
Documento de la aplicación
Documento de contenidos
XPath
Generación
esquema
navegacional
(
Controlador de eventos
incorporado
(
Generación
páginas
HTML
GAP
(
Transformación XSLT
(
Esquema navegacional Swing
HyperlinkListener Swing
Páginas HTML
Aplicación hipermedia

Page 17
NOVATICA/UPGRADE jul./ago. 2002 nº158
20 Edición digital/ ©ATI 2002
misma). El DSL de la aplicación surge como la combinación
de un lenguaje de marcas para representar diagramas, un
lenguaje para representar grafos dirigidos valorados, un
lenguaje para describir interfaces gráficas de usuario y un
lenguaje para describir interacciones (siguiendo un modelo
de interacción basado en autómatas). Las descripciones del
diagrama y del grafo se obtienen transformando los conte-
nidos mediante transformaciones XSLT.
5. Conclusiones y trabajo futuro
Desde nuestro punto de vista, los lenguajes de marcado y las
tecnologías XML asociadas constituyen un mecanismo ideal
para la construcción de aplicaciones que, como los hipermedia
educativos, hacen un uso intensivo de la información. XML
proporciona legilibilidad y declaratividad. También permi-
te hacer explícita la estructuración de la información sobre
un dominio concreto. Además, al combinar XML con len-
guajes de programación como Java, podemos tener una
independencia total de plataforma, pudiendo portar nues-
tras aplicaciones a diferentes entornos.
Por otro lado la separación de los distintos aspectos que
componen una aplicación permite cambios en uno de ellos
sin afectar (o afectando levemente) al otro. Esto permite la
generación rápida de prototipos/aplicaciones, simplifican-
do el mantenimiento y la reutilización de información. De
esta forma, una vez que se ha caracterizado adecuadamente
un dominio, pueden proporcionarse lenguajes de
marcas específicos para dicho dominio, junto con
un procesador de dichos lenguajes que genere
automáticamente las aplicaciones a partir de su
descripción como documentos estructurados. La
aplicación de técnicas operacionales como DTC
facilitan la construcción de dichos procesadores
mediante la combinación de procesadores más
simples.
Actualmente estamos estudiando la ampliación de
GAP para soportar totalmente las capacidades
expresivas de Pipe, a la vez que analizamos la
posibilidad de combinar estas técnicas con otros
formalismos de representación de contenidos (p. ej., el
formato relacional) y su incorporación efectiva al documen-
to de la aplicación. El siguiente paso es profundizar en las
capacidades de extensibilidad y modularidad que brinda la
aproximación de DTC para construir intérpretes modulares
para los DSLs de un tipo concreto de aplicaciones. Así
mismo, tenemos previsto realizar una caracterización más
exhaustiva del tipo de aplicaciones para las que la aproxima-
ción DTC puede resultar competitiva, así como un análisis
de las herramientas CASE necesarias para facilitar su
aplicación en un entorno industrial de desarrollo.
Referencias
[1] Abelson, H., Sussman,G.J.
The Structure and Interpretation of Computer
Programs. Second Edition.
McGraw Hill. 1996.
[2] Deursen, A.van,Klint,P.,Visser,J.
Domain Specific Languages: An
Annotated Bibliography.
ACM SIGPLAN Notices 35(6), pp 26-36. 2000.
[3] Fernández-Manjón, B., Fernández-Valmayor A., Navarro, A.
Extending
Web educational applications via SGML structuring and content-based
capabilities
. F. Verdejo y G. Davies (eds.), The Virtual Campus: Trends for
Higher Education and Training, pp 244-259. Chapman & Hall, Londres, 1997.
[4] Goldfard,C.F.
The SGML Handbook
. Oxford University Press, 1990.
Oxford University Press,1990.
[5] Halasz F., Schwartz M.
The Dexter Hypertext Reference Model
.
Communications of the ACM 37 (2), 30-39, 1994.
[6] Hardman L., Bulterman D.C.A., van Rossum G.
The Amsterdam
Hypermedia Model: Adding Time and Context to the Dexter Model
.
Communications of the ACM 37 (2), 50-62, 1994.
[7] International Organization for Standarization.
DSSSL ­ Document Style
Semantics and Specification Language
. ISO/IEC 10179. 1996.
[8] International Organization for Standarization.
Hypermedia/Time-based
Structuring Language (HyTime) ­ 2md Edition
. ISO/IEC 10744, 1997.
Figura 3. Documento de la aplicación y prototipo
<!DOCTYPE aplicacion SYSTEM "aplicacion.dtd">
<aplicacion id="tutorialesXML">
<ventana id= "v1">
<nombre>ventana 1</nombre>
<panel id= "p1.1" tam=" 140, 320">
<contenidoPanel>
<contenidoDefecto>/contenidos/índice</contenidoDefecto>
</contenidoPanel>
<destinoEnlaces panel="p1.2"/>
</panel>
<panel id= "p1.2" tam="320, 200">
<contenidoPanel>
<contenidoGrupo>/contenidos/subÍndices</contenidoGrupo>
</contenidoPanel>
<destinoEnlaces panel="p1.3"/>
</panel>
<panel id= "p1.3" tam="400, 500">
<contenidoPanel>
<contenidoGrupo>/contenidos/contenidos</contenidoGrupo>
</contenidoPanel>
</panel>
</ventana>
</aplicacion>
Figura 4. Esquema de la generación de una aplicación en DTC
siguiendo la estrategia de análisis y evaluación.
Aplicación
ejecutable
Contenidos
Transformaciones
XSLT
Descripción (parcial)
de la aplicación
Transformación
de contenidos
Descripción de la
aplicación
Arbol DOM
Parsing
(construcción árbol
DOM)
Análisis
Aplicación
Interpretación
Evaluación

Page 18
NOVATICA/UPGRADE jul../ago. 2002 nº158
Edición digital/ ©ATI 2002 21
Figura 5. Aplicación de búsqueda de caminos mínimos en redes de metro generada con DTC
<RedDeMetro>
...
<Estaciones>
<Estación id="Rubén_Darío">
<Accesos>
<Acceso id="Acceso_A_Rubén_Darío"/>
</Accesos>
<Andenes>
<Anden id="Anden1_de_Rubén_Darío_en_lin4"
Linea="lin4"
Sentido="Canillejas"/>
...
Contenidos:
Descripción de la red de
metro
Transformaciones XSLT:
Generación del diagrama y
del grafo dirigido valorado
a partir de la descripción de
la red
Descripción de la
aplicación: Utilización de
DSLs para describir grafos
dirigidos valorados,
diagramas, GUIs e
interacción basada en
autómatas
Intérprete
Componentes Software
...
<xsl:template match="Estación">
<nodo id="{@id}"/>
<xsl:apply-templates/>
</xsl:template>
<xsl:template match="Andén">
<nodo id="{@id}"/>
</xsl:template>
...
<ApMetro>
...
<Espacio/>
<Botones filas="2"
columnas="1"
id="botones">
<Botón fila="0" columna="0"
id="reset">Reset</Botón>
<Botón fila="1 columna="0"
id="exit">Exit</Botón>
...
[9] Liang,S.,Hudak,P.,Jones,M.P.
Monad Transformers and Modular
Interpreters
. 22
nd
ACM SIGPLAN-SIGACT Symposium on Principles of
Programming Languages. San Francisco, CA. 1995.
[10] Navarro, A., Fernández-Manjón, B., Fernández-Valmayor, A., Sierra,
J.L.
A Practical Methodology for the Development of Educational Hypermedias
.
International Conference on Educational Uses of Information and Communication
Technologies, ICEUT 2000, que es parte del 16
th
IFIP World Computer Congress
2000, Information Processing Beyond Year 2000, pp 217-220. Beijing, 2000.
[11] Navarro, A., Fernández-Manjón, B., Fernández-Valmayor, A., Sierra,
J.L.
Formal-Driven Conceptualization and Prototyping of Hypermedia
Applications
. Fundamentals Approaches to Software Engineering 2002, FASE
2002, que forma parte de European joint conferences on Theory and Practice of
Software 2002, ETAPS 2002, pp. 308-322. Grenoble, 6-14 abril, 2002. Publi-
cado como
Lecture Notes in Computer Science
(Vol. 2306), Springer-Verlag,
Berlin, 2002.
[12] Navarro, A., Fernández-Valmayor A, Fernández-Manjón, B., Sierra,
J.L.
Using Analysis, Design and Development of Hypermedia Applications in
the Educational Domain
. M. Ortega y J. Bravo (Eds), Computers and Education:
Towards an Interconnected Society, pp 251-260. Kluwer Academic Publisher,
Holanda, 2001.
[13] Sierra, J.L, Fernández-Manjón, B., Fernández-Valmayor, A, Nava-
rro, A.
Integration of Markup Languages, Document Transformations and
Software Components in the Development of Applications: The DTC Approach
.
International Conference on Software: Theory and Practice, ICS'2000, que es
parte del 16
th
IFIP World Computer Congress 2000, Information Processing
Beyond Year 2000, pp 217-220. Beijing, 2000.
[14] Sierra, J.L, Fernández-Valmayor, A., Fernández-Manjón, B., Nava-
rro, A.
Operationalizing Application Descriptions with DTC: Building
Applications With Generalized Markup Technologies
. 13
th
International
Conference on Software Engineering and Knowledge Engineering SEKE'01, pp
379-386. Buenos Aires. 2001.
[15] World Wide Web Consortium.
Document Object Model (DOM) Level
2
(varios volúmenes): <http://www.w3c.org/DOM/DOMTR>, 2000.
[16] World Wide Web Consortium.
Extensible Markup Language (XML) 1.0
(Second Edition)
: <http://www.w3.org/TR/REC-xml>, 2000.
[17] World Wide Web Consortium.
Extensible Stylesheet Language (XSL)
Version 1.0.
: <http://www.w3.org/TR/xsl/>, 2001.
[18] World Wide Web Consortium.
Synchronized Multimedia Integration
Language (SMIL 2.0)
: <http://www.w3.org/TR/smil20/>, 2001.
[19] World Wide Web Consortium.
XML Linking Language (XLink) Version
1.0
.: <http://www.w3.org/TR/xlink/>, 2001.
[20] World Wide Web Consortium.
XML Path Language (XPath) Version
1.0
.: <http://www.w3c.org/TR/xpath/>, 1999.
[21] World Wide Web Consortium.
XML Pointer Language (XPointer)
Version 1.0
.: <http://www.w3c.org/TR/xptr/>, 2001.
[22] World Wide Web Consortium.
XML Schema Parts 0,1,2
.: <http://
www.w3c.org/XML/Schema/> 2001.
[23] World Wide Web Consortium.
XSL Transformations (XSLT) Version
1.0
.: <http://www.w3.org/TR/xslt/>, 1999.
Notas
1
XML es, en realidad, una versión simplificada de SGML para su uso en WWW.
2
En el contexto de XML, una
aplicación
es sinónimo de un lenguaje de marcado
definido mediante XML.
3
XSL es el resultado de integrar
tres
lenguajes: un lenguaje de consulta (XPath),
un lenguaje de transformación (XSLT) y un lenguaje de
objetos de formato
.

Page 19
NOVATICA/UPGRADE jul./ago. 2002 nº158
22 Edición digital/ ©ATI 2002
MONOGRAFÍA
XML: ¿el ASCII del siglo XXI?
Resumen:
actualmente se está desarrollando toda una nue-
va tecnología basada en los estándares XML para el proce-
samiento de consultas sobre fuentes de datos heterogéneas.
Esto incluye especificación de lenguajes de consultas, técni-
cas para la mediación e integración de fuentes de datos, etc.
El siguiente gran reto consiste en desarrollar lo que ya se
conoce como la Web Semántica a partir de toda esta tecno-
logía. Precisamente es el tratamiento eficiente de la infor-
mación, contenida en las capas lógica y ontológica, lo que
se plantea como uno de los factores principales que determi-
narán su éxito práctico
.
Palabras clave:
integración de datos, procesamiento de con-
sultas basado en ontologías, web, semántica.
1. Introducción
Desde que Internet se convirtió en la red global de las comuni-
caciones y en un entorno para el desarrollo de sistemas de
información, se hizo evidente que era necesario algo más que
paginas HTML estáticas. Tras la aparición de XML (
eXtensive
Markup Language
) como una forma de describir datos
estructurados y semiestructurados, el
World Wide Web
Consortium
(W3C) ha ido desarrollando tecnología alrededor
de este nuevo estándar. Destacan: XMLS (
Extensible Markup
Language Schemas
), RDF (
Resource Description Framework
),
RDF-Schema, XSL/XSLT (
Extensible Stylesheet Language/
Transformation
) y SOAP (
Simple Object Access Protocol
).
Estas recomendaciones, junto con el uso de XML como formato
para el intercambio electrónico de datos, abren la posibilidad de
integrar fuentes de datos heterogéneas en el entorno de la Web.
Como consecuencia de esto, las empresas más importantes de
desarrollo de software como Oracle, Microsoft e IBM, por
ejemplo, han introducido soporte para XML en sus bases de
datos y productos.
Toda esta tecnología ha hecho posible el desarrollo de
nuevas aplicaciones que ya no requieren de la interacción
humana, haciendo a la Web más «entendible» por las
máquinas. Berners-Lee, el inventor de la Web, describe la
Web semántica como el siguiente paso en la evolución de las
aplicaciones Web, donde «la información tiene un significa-
do bien definido, posibilitando que los ordenadores y las
personas trabajen en cooperación» [8].
El desarrollo de la Web Semántica pasa por la adopción de
diferentes tecnologías (
figura 1
), que permitan añadir sig-
Viabilidad práctica de la
evaluación de consultas en
la Web Semántica
José Francisco Aldana Montes, Antonio César
Gómez, Nathalie Moreno Vergara, María del
Mar Roldán García
Depto. de Lenguajes y Ciencias de la Computación,
E.T.S de Ingeniería Informática, Universidad de Málaga
<{jfam, cesar, vergara, mmar}@lcc.uma.es>
Autores
José Francisco Aldana Montes
, doctor en Informática desde
1998, es profesor titular en el departamento de Lenguajes y
Ciencias de la Computación de La Universidad de Málaga y
miembro del comité de programa de las JISBD desde 1999. Su
línea de investigación actual se sitúa en el marco de la integra-
ción de la tecnología de bases de datos en la Web, más
concretamente en el campo del procesamiento de consultas.
Temas de su interés son: la evaluación (distribuida) y optimización
de consultas recursivas; la evaluación distribuida de consultas
XQuery; la optimización (semántica) de consultas XQuery; la
integración semántica y modelos teóricos para la Web Semán-
tica; y el procesamiento de consultas en la Web Semántica.
Antonio César Gómez Lora
es Profesor Ayudante en el
Departamento de Lenguajes y Ciencias de la Computación de
la Universidad de Málaga. Recibió su título de Ingeniero en
Informática en la Universidad de Málaga en 1997 y actualmente
se encuentra desarrollando su Tesis Doctoral en esta Universi-
dad. Sus intereses en investigación incluyen técnicas híbridas
para la evaluación y optimización de consultas recursivas en
sistemas distribuidos, así como técnicas de optimización en
tiempo de evaluación.
Mª del Mar Roldán García
es Becaria de Investigación en el
Departamento de Lenguajes y Ciencias de la Computación de
la Universidad de Málaga. Recibió su título de Ingeniero en
Informática en la Universidad de Málaga en 2000 y actualmente
se encuentra desarrollando su Tesis Doctoral en esta Universi-
dad. Sus intereses en investigación incluyen integración de
fuentes de datos heterogéneas, ontologías y técnicas de
indexación.
Nathalie Moreno Vergara
es Becaria de Investigación en el
Departamento de Lenguajes y Ciencias de la Computación
de la Universidad de Málaga. Recibió su título de Ingeniero
en Informática en la Universidad de Málaga en 2000 y
actualmente se encuentra desarrollando su Tesis Doctoral
en esta Universidad. Sus interesen en investigación están
centrados en el campo de las ontologías, la integración
semántica y el desarrollo
nificado a la estructura de los documentos XML y describir
la información semántica necesaria para que la procesen las
máquinas. Desde hace tiempo este problema se ha abordado
mediante «ontologías» descritas como documentos o fiche-
ros «que formalmente definen las relaciones entre térmi-
nos». Las ontologías permiten trabajar con conceptos, en
lugar de palabras clave, en los sistemas de recuperación de
la información. Desde el punto de vista de las fuentes de
información, las ontologías describen el contenido de los
repositorios de datos independientemente de la representa-

Page 20
NOVATICA/UPGRADE jul../ago. 2002 nº158
Edición digital/ ©ATI 2002 23
ción sintáctica de los mismos, posibilitando su integración
semántica [7].
Un problema que surgirá en el futuro próximo debido a la
gran proliferación de ontologías específicas (y estándares
para metadatos), es el de la integración de estas.
2. Lenguajes para la Web Semántica
Para materializar una conceptualización u ontología, se
requiere un lenguaje de representación del conocimiento.
Tradicionalmente, estos lenguajes han sido desarrollados en
el campo de la Inteligencia Artificial y fijan su base formal
sobre paradigmas como: el cálculo de predicados de primer
y segundo orden, la lógica de descripciones o la orientación
a objetos. Son las distintas propiedades computacionales y
expresivas, las que diferencian a posteriori estos lenguajes.
Entre los más destacados se encuentran Ontilingua, Loom,
OCML y Flogic.
Con la aparición de XML como estándar de facto para el
intercambio de datos entre aplicaciones, aparecen lenguajes
de representación del conocimiento para la Web; los cuales
invitan a la publicación de ontologías usando la sintaxis de
dicho estándar. Se evita así, en la medida de lo posible, la
ardua tarea de tener que definir
parsers
. Estos lenguajes
basados en XML son candidatos idóneos para la WS. SHOE
(
Simple HTML Ontology Extensions
), XOL (
Exchange
Ontology Language
), OML (
Ontology Markup Language
)
y RDFS (
Resource Description Framework Schema
Language
), son algunos de ellos. Heredan las etiquetas de
XML e incorporan nuevas características que mejoran la
expresividad del modelo de datos inicial. A la lista anterior
se suman otras propuestas que extienden RDF y RDFS,
como son OIL (
Ontology Interchange Language
) y su
sucesor DAML+OIL.
Dado que XML impone la necesidad de una restricción
estructural (un núcleo común) para proporcionar métodos
inequívocos de expresión semántica, RDF no es más que la
infraestructura que permite esa restricción gracias a la
codificación, reutilización e intercambio de metadatos
estructurados. Así, RDF es el modelo más prometedor para
asociar información al contenido de recursos web.
No es probable que un solo lenguaje cubra todas las nece-
sidades y requisitos que se presentan en la Web Semántica.
Un análisis de las características más deseadas, en cuanto a
expresividad y potencia de sus mecanismos de razonamien-
to, nos proporcionará el perfil de un lenguaje eficiente para
el entorno de la Web Semántica.
Se establece una clara distinción entre los términos: repre-
sentación de conocimiento y razonamiento. La formalización
del conocimiento se realiza, en la mayoría de los casos,
mediante el uso de: conceptos, relaciones n-arias, funciones,
procedimientos, instancias, axiomas, reglas de producción
y podríamos añadir también mediante semántica formal.
Estos parámetros determinan la expresividad del lenguaje.
La
tabla 1
muestra una comparativa en función de esos
términos, donde el símbolo `+' indica un aspecto soportado
por el lenguaje, el símbolo `-` indica un aspecto no soporta-
do, `+/-` indica un aspecto no soportado directamente pero
que puede modelarse con los recursos que ofrece el lenguaje
y las siglas `N.D.' hacen referencia a aspectos no soporta-
dos, pero que tampoco son excesivamente relevantes.
Nótese como los lenguajes basados en XML no suelen
ofrecer la capacidad de definir funciones, procedimientos y
axiomas, excepto alguna forma restringida de axiomatización
como son las reglas deductivas en el caso de SHOE. Carecen,
igualmente, de una semántica formal inherente al lenguaje.
Esto dificulta la implementación de mecanismos eficientes
de razonamiento. En este sentido, Ontolingua es quizás el
más expresivo de los formalismos presentados, aunque no
existe actualmente ninguna máquina de inferencia que lo
implemente.
Otra comparativa interesante podríamos realizarla en función
de los mecanismos de razonamiento que permite el lenguaje. La
tabla 2
recoge estos aspectos. OIL dispone de un sistema de
clasificación automático (deseable en el caso de las ontologías),
Flogic implementa el manejo de excepciones y ambos presen-
tan sistemas de inferencia correctos y completos. Frente a los
lenguajes basados en XML, los lenguajes tradicionales sopor-
tan la ejecución de procedimientos, el mantenimiento de
restricciones, y la evaluación tanto
top-down
como
bottom-up.
Así se plantea un interesante compromiso entre la potencia y la
completitud de los mecanismos de inferencia empleados, y su
eficiencia, que hace muy interesante el estudio y desarrollo de
técnicas para la evaluación de programas lógicos distribuidos
en el contexto de su uso. Técnicas que den soporte al procesa-
miento de consultas, basado en ontologías, dentro de la web
semántica.
Figura 1. Visión de la Web Semántica presentada por Berners-Lee

Page 21
NOVATICA/UPGRADE jul./ago. 2002 nº158
24 Edición digital/ ©ATI 2002
Tabla 2. Mecanismos de razonamiento del lenguaje, presentada en [5]
2. Un marco para la Web Semántica: impli-
caciones prácticas
Heflin propone un nuevo marco for-
mal para la representación del conoci-
miento en la Web Semántica basado
en ontologías [6]. A nosotros nos
interesa la aplicación de ese marco
genérico para la integración y consul-
ta de servicios Web. Aunque Heflin va
ampliando la definición formal de
ontología durante su desarrollo, para
simplificar la exposición nos basta
con una de las primeras definiciones
que realiza.
Se entiende una ontología como una
terna O = <V, A, E>, donde V se
corresponde con el vocabulario, A
es el conjunto de axiomas y E es el
conjunto de ontologías que son ex-
tendidas por O. Así mismo, existen
dos funciones asociadas a los recur-
sos: C(r) que determina el conjunto
de ontologías con el que se compro-
mete el recurso r; y K(r) que traduce
la información del recurso r, intro-
duciéndola en la teoría formal en
términos del vocabulario de la onto-
logía (modelando, en cierta forma,
el concepto de
wrapping
).
En la
figura 2
podemos ver, en nota-
ción gráfica, un ejemplo en el que
tanto la O
U
como O
F
extienden a O
G
.
Por otro lado, tenemos la perspectiva
(concepto básico en este marco) de O
U
en la
figura 2
. En el modelo presenta-
do por Heflin, las consultas se realizan
sobre las perspectivas de la ontología.
Sea PO
U
la perspectiva definida sobre
la ontología O
U
como la unión de: los
axiomas de la ontología O
U,
los axio-
mas de todas las ontologías extendi-
das por O
U
, las funciones de conoci-
miento de todos los recursos que se
comprometen con la ontología O
U
y
las funciones de conocimiento de to-
dos los recursos que se comprometen
todas las ontologías que son extendi-
das por O
U
.
Este marco formal se puede desa-
rrollar de múltiples formas en base
a distintos modelos de
implementación, cada uno de los
cuales tiene importantes
implicaciones prácticas (desde el
punto de vista de la viabilidad y eficiencia de su
implementación) y teóricas (planteando, incluso, la necesi-
dad de extender --particularizar-- el modelo anterior).
El escenario más ingenuo para la Web Semántica sería aquel
Tabla 1. Comparación de los lenguajes en función de los elementos
para representar el dominio del conocimiento, presentada en [5]

Page 22
NOVATICA/UPGRADE jul../ago. 2002 nº158
Edición digital/ ©ATI 2002 25
en el que todas las fuentes de datos se comprometen con un
conjunto reducido de ontologías universalmente aceptadas y
conocidas. Donde además todas las fuentes de datos son
accesibles de forma homogénea y universal. Así cada siste-
ma recopilaría rápidamente los axiomas y recursos de su
perspectiva y los procesaría. Es evidente que este escenario
no tiene demasiada credibilidad como arquitectura básica
para la Web Semántica. No es de esperar que todo el mundo
se comprometa con un grupo reducido de ontologías, ni
tampoco es de esperar que un sistema aislado pueda compu-
tar una perspectiva completa que involucre a un gran número
de recursos. Es más fácil imaginar que van a existir numero-
sas ontologías y numerosos sistemas encargados de evaluar
ontologías específicas (SEO
i
). Así las perspectivas deberán
ser construidas de forma cooperativa gracias a la interacción
de estos agentes o sistemas. En este contexto es imprescin-
dible respetar la interoperabilidad y autonomía de los SEO
i
.
Esto requiere de un cierto aislamiento a distintos niveles, que
analizaremos desde tres dimensiones distintas. Cada una de
ellas presenta un conjunto particular de problemas que deben
ser estudiados en relación a aspectos como: pro-
piedad intelectual, heterogeneidad y distribución.
Desde el punto de vista de la propiedad intelectual
una empresa puede querer aislar o proteger las
fuentes de datos y/o los axiomas que definen los
elementos del vocabulario de su ontología. De los
tres elementos básicos que componen el modelo
de una ontología, a saber, el vocabulario, los
axiomas y las fuentes de datos modeladas por la
función de conocimiento K(r), sólo el primero de
ellos debe ser necesariamente público (total o
parcialmente).
La segunda dimensión sobre la que trabajamos es
la heterogeneidad, entendida sobre dos factores
claves: el formalismo y el mecanismo de inferen-
cia. Las extensión de una ontología debería poder
ser realizada aún cuando se utilizaran dos forma-
lismos diferentes para representar los axiomas.
Así mismo también dos sistemas basados en
ontologías pueden utilizar mecanismos de
inferencia diferentes para computar los he-
chos de dichos axiomas.
En el modelo de implementación ingenuo
del marco de Heflin se podría pensar, de
forma acertada, que la heterogeneidad en el
formalismo se puede solucionar incorporan-
do un traductor. Sin embargo, un caso extre-
mo, pero real y frecuente, de heterogeneidad
corresponde a la declaración de Servicios de
Valor Añadido (SVA). Un SVA dentro de
un sistema de integración o mediación pue-
de ser interpretado como una funcionalidad
extra que se le incorpora al sistema y cuya
semántica no es, y generalmente no puede
ser, expresada en el lenguaje utilizado para
la integración. El concepto de SVA aparece
en múltiples campos, como por ejemplo los
procedimientos almacenados y procedimientos externos en
gestores relacionales, los predicados externos en lenguajes
lógicos, etc. En el marco de Heflin esto se correspondería con
predicados de la ontología cuya definición no es conveniente
realizarla o no puede ser realizada en el formalismo utilizado
para expresar el conjunto de axiomas.
El análisis de la tercera dimensión, que hemos denominado
simplemente distribución, está orientado a considerar as-
pectos que son de suma importancia para la viabilidad real
de la Web Semántica. Existen dos puntos de vista básicos en
la distribución: el primero referido a la evaluación de la
ontología y el segundo referido a la optimización de dicha
evaluación. Dentro de la evaluación nos encontraríamos con
aspectos tan importantes como replicación, equilibrado de
carga y nivel de tolerancia a fallos (fallos imputable tanto a
pérdidas --no accesibilidad-- de fuentes de datos como a
pérdidas de sistemas o agentes de evaluación).
r
2
r
1
r
3
r
4
V = {
Thing
,
Person
,
Object
}
A={
Person
(X)
Thing
(X),
Object
(X)
Thing
(X) }
E = {
}
K(r
1
)={
Person
(
bob
)}
K(r
2
)={
Object
(sofa52)}
C(r
1
)
C(r
2)
O
G
V = {
Chair
,
Person
,
Object
}
A={
Chair
(X)
O
G
:
Person
(X),
Person
(X)
O
G
:
Person
(X),
Object
(X)
O
G
:
Object
(X)}
E={O
G
}
K(r
3
)={
Chair
(
kate
)}
C(r
3
)
O
U
V = {
Chair
,
Person
,
Object
}
A={
Chair
(X)
O
G
:
Object
(X),
Person
(X)
O
G
:
Person
(X)
Object
(X)
O
G
:
Object
(X)}
E={O
G
}
K(r
4
)={
Chair
(recliner29)}
C(r
4)
O
F
r
2
r
1
r
1
r
3
r
3
r
4
r
4
V = {
Thing
,
Person
,
Object
}
A={
Person
(X)
Thing
(X),
Object
(X)
Thing
(X) }
E = {
}
K(r
1
)={
Person
(
bob
)}
K(r
2
)={
Object
(sofa52)}
C(r
1
)
C(r
2)
O
G
V = {
Chair
,
Person
,
Object
}
A={
Chair
(X)
O
G
:
Person
(X),
Person
(X)
O
G
:
Person
(X),
Object
(X)
O
G
:
Object
(X)}
E={O
G
}
K(r
3
)={
Chair
(
kate
)}
C(r
3
)
O
U
V = {
Chair
,
Person
,
Object
}
A={
Chair
(X)
O
G
:
Object
(X),
Person
(X)
O
G
:
Person
(X)
Object
(X)
O
G
:
Object
(X)}
E={O
G
}
K(r
4
)={
Chair
(recliner29)}
C(r
4)
O
F
Figura 2. Ejemplo de ontologías extraído de [6]
Figura 3. Teoría formal equivalente a la perspectiva de O
U
en el ejemplo de la figura2

Page 23
NOVATICA/UPGRADE jul./ago. 2002 nº158
26 Edición digital/ ©ATI 2002
r
3
V = { Thing, Person, Object }
O
G
V = { Chair, Person, Object }
A={Chair(X)
O
G
:Person (X),
Person(X)
O
G
:Person(X),
Object(X)
O
G
:Object (X)}
E={O
G
}
K(r
3
)={Chair (kate)}
C(r
3
)
O
U
r
3
r
3
V = { Thing, Person, Object }
O
G
V = { Chair, Person, Object }
A={Chair(X)
O
G
:Person (X),
Person(X)
O
G
:Person(X),
Object(X)
O
G
:Object (X)}
E={O
G
}
K(r
3
)={Chair (kate)}
C(r
3
)
O
U
Figura 4. Opacidad en la perspectiva de O
U
En segundo lugar, las técnicas de optimización cambian
radicalmente al considerar aspectos de opacidad en cuanto
a recursos, axiomas, etc.
En definitiva y retomando el ejemplo de la
figura 2
, para
mantener la heterogeneidad y la autonomía deberíamos
obtener la misma PO
U
(
figura 3
), en un contexto donde
únicamente se conoce la parte del esquema mostrado en la
figura 4
.
Mantener la perspectiva original siguiendo este esquema
introduce nuevos problemas, pues requiere que los sistemas
encargados de evaluar O
U
(SEO
U
) y O
G
(SEO
G
) interactúen
para llegar a la solución. Esta interacción es mucho más
compleja que el simple uso SEO
G
por parte de SEO
U
. Ambos
deben cooperar para llegar a una solución válida. Por
ejemplo, de PO
U
se infiere O
G
:Person(kate), que a su vez
inferirá O
G
:Thing(kate) --véase
figura 3
. Así si SEO
U
interroga a SEO
G
sobre ¿es cierto que Person(kate)? en un
entorno distribuido (donde SEO
U
y SEO
G
no tengan infor-
mación completa) SEO
G
debería responder «no» o «no sé»
(según use o no la hipótesis del mundo cerrado), en el mejor
de los casos.
Desde el punto de vista de reconstruir PO
U
sin violar la
autonomía de las ontologías ni forzar una evaluación centra-
lizada, si SEO
U
no preguntara sino que informa a SEO
G
de
que Person(kate) que es cierto en PO
U
, SEO
G
ahora no sólo
conocerá este hecho sino que, además, debe responder que
también es cierto Thing(kate) en PO
U
.
Estas interacciones se vuelven más complejas si además
tenemos en cuenta que, dentro del ámbito de una consulta,
la respuesta a una de ellas sigue un modelo markoviano. En
el ejemplo anterior esto equivale a «recordar» los nuevos
hechos Person(kate) y Thing(kate) para futuras interacciones.
Actualmente estamos trabajando en el desarrollo del marco
formal anterior, adaptando y desarrollando técnicas de bases
de datos para conseguir una implementación prác-
tica del modelo que hemos descrito. Nos basamos
en nuestra experiencia previa en la evaluación
distribuida y optimización de programas lógicos
distribuidos mediante un modelo de flujo de datos
(D
3
--
Distributed Dataflow Datalog
) [1], [2] y en el
desarrollo posterior de sistemas mediadores basa-
dos en éste (D
3
-Web) [3] además de en los nuevos
trabajos que están siendo desarrollados en Data
Stream Systems [4].
3. Conclusiones
La Web Semántica va a seguir un modelo de
crecimiento similar a la Web y su éxito depende de
que seamos capaces de elaborar técnicas realistas
que hagan viable éste modelo de desarrollo. El
compromiso adoptado entre los conceptos de po-
tencia, completitud y eficiencia, para cada uno de
los distintos mecanismos de inferencia, abrirá un
amplio abanico de estudio en torno a nuevas
técnicas de evaluación --basadas en ontologías--
para programas lógicos y distribuidos dentro del
contexto de la Web Semántica.
Por otro lado, la consulta y gestión eficiente de grandes bases de
conocimiento distribuidas tiene aún muchos aspectos no resuel-
tos, relacionados ­ entre otras cosas - con la integración eficiente
de información y el desarrollo de mecanismos de inferencia
distribuidos.
Referencias
[1] J. F. Aldana,
Un Modelo de Flujo de Datos para la Evaluación de
Consultas en Bases de Datos Deductivas. Tesis Doctoral. Universidad de
Málaga. 1998.
[2] J. F. Aldana, J. M. Troya,
DataFlow Evaluation of Datalog Queries, en:
International Joint Conference and Symposium on Logic Programming
,
Bonn, Alemania (1996), 69-78.
[3] J. F. Aldana, M. I. Yagüe,
WWW as a Distributed Deductive Database,
en:
8th International Conference on Management of Data
, Madras, La
India (1997), 277-292.
[4] B. Babcock, S. Babu, M. Datar, R. Motwani, J. Widom,
Models and
Issues in Data Stream Systems.
21
st
ACM SIGACT-SIGMOD-SIGART
Symposium on Principles of Database Systems
(PODS), (2002).
[5] O. Corcho, A. Gómez.
A Roadmap to Ontology specification Languages.
Procedings of Knowledge Adquisition, Modelling and Managemente
, 12
th
International Conference, EKAW 2000. Lecture Notes in
Computer Science,
1937, Springer, 2000.
[6] J. D. Heflin.
Towards the Semantic Web: Knowledge Representation in
a Dynamic, Distributed Environment, PhD Thesis, 2001.
[7] E. Mena, A. Illaramendi, V. Kashyap, A.P. Sheth
«OBSERVER: An
Approach for Query Processing in Global Information systems based on
Interoperation Across Pre-Existing Ontologies». Distributed and
Parallel
Databases
8(2), 2000.
[8] T. Berners-Lee, J. Hendler, O. Lassila.
The Semantic Web.
Scientific
American
. Mayo 2001. <http://www.sciam. com/2001/0501issue/
0501berners>

Page 24
NOVATICA/UPGRADE jul../ago. 2002 nº158
Edición digital/ ©ATI 2002 27
MONOGRAFÍA
XML: ¿el ASCII del siglo XXI?
Firma y cifrado digital con XML
Resumen:
las aplicaciones de comercio electrónico han encontra-
do en XML un gran aliado, ya que permite la utilización de
etiquetas de marcas consensuadas o estandarizadas para estruc-
turar los documentos de comercio, cuyo tratamiento puede ser
procesado automáticamente en sistemas de información
heterogéneos. La aplicación a XML de los mecanismos de seguri-
dad, necesarios en las transacciones electrónicas, sólo tiene
sentido si además se emplean estándares para la firma y el cifrado
electrónicos. Este artículo describe los estándares que el W3C está
desarrollando en este campo, así como dos plataformas de
comercio electrónico que hacen uso de dichos estándares: ebXML,
estándar en proceso de definición avalado por OASIS y UN/
CEFACT, y x-SPEED, un protocolo de pagos diseñado e
implementado por el grupo de investigación ANTS de la Facultad
de Informática de la Universidad de Murcia.
Palabras clave:
XML, firma digital, cifrado digital, W3C,
IETF, ebXML, SOAP, x-SPEED.
1. Introducción
En los tiempos que corren XML se ha convertido en un eficaz
mecanismo para el intercambio de datos a través de Internet,
siendo el comercio electrónico una de las áreas en las que está
jugando un papel decisivo. Uno de los factores clave a tener en
cuenta en un escenario de comercio electrónico es la aportación
de seguridad a las comunicaciones, para evitar que la informa-
ción sensible que se intercambia a través de la red sea consul-
tada o manipulada por terceros. ¿Cómo podemos aportar
seguridad a XML (
eXtensible Markup Language
)? Una forma
sencilla es considerar un documento XML como un documento
binario cualquiera y aplicar algún mecanismo criptográfico
para firmar o cifrar documentos arbitrarios. Pero este método
se caracteriza por su falta de flexibilidad, ya que sólo permite
firmar o cifrar documentos XML completos. ¿Y si lo que
necesitamos es, por ejemplo, cifrar distintas partes de un
documento XML para distintos destinatarios? ¿O firmar
fragmentos de un documento por emisores diferentes? ¿O
combinar la firma y el cifrado sobre partes de un documento de
forma simultánea y utilizando cualquier orden imaginable? La
solución a todas estas cuestiones la encontramos en los estándares
de firma y cifrado XML que están siendo desarrollados por
grupos de trabajo conjuntos entre el IETF (
Internet Engineering
Task Force
) y la W3C (
World Wide Web Consortium
), y que
nos describen cómo aplicar la firma digital y el cifrado sobre
XML de una manera extraordinariamente flexible y potente.
2. La firma digital con XML
La firma XML [1] puede aplicarse a cualquier contenido de
datos, siendo posible firmar documentos binarios arbitra-
rios, documentos XML completos o fragmentos de un
Antonio F. Gómez Skarmeta, María Encarnación
Martínez González, Eduardo Martínez Graciá,
Gregorio Martínez Pérez
Grupo de Investigación ANTS, Depto. de Ingeniería de
la Información y las Comunicaciones (DIIC), Facultad
de Informática, Universidad de Murcia
<{skarmeta, encarna, gregorio}@dif.um.es>,
<edumart@um.es>
Autores
Antonio F. Gómez Skarmeta
se licenció en Informática por la
Universidad de Granada, doctorándose también en Informática
por la Universidad de Murcia. Desde 1993 es Profesor Titular en
el departamento de Ingeniería de la Información y las Comuni-
caciones de la Universidad de Murcia. Ha trabajado en nume-
rosos proyectos de investigación tanto en el área de los inteli-
gencia artificial distribuida (proyecto M2D2), como en el del
comercio electrónico (PISCIS), así como en tele-enseñanza y
trabajo colaborativa (PUPITRE-NET) y nuevos servicios avan-
zados sobre redes de banda ancha (SABA). Actualmente
participa en diversos proyectos europeos del ámbito de la tele-
enseñanza y el aprendizaje a distancia COLAB e ITCOLE, así
como en el proyecto de implantación de IPv6 EURO6IX donde
coordina aspectos de seguridad. Ha publicado mas de 40
trabajos de índole internacional
Maria Encarnación Martínez González
es Ingeniero en Infor-
mática por la Universidad de Murcia. Actualmente desempeña
tareas de investigación y desarrollo en la misma Universidad.
Sus principales áreas de interés son XML y la seguridad en las
comunicaciones.
Eduardo Martínez Graciá
es Ingeniero en Informática por la
Universidad de Murcia. Actualmente es Profesor Ayudante de
Escuela en el Departamento de Ingeniería de la Información y
las Comunicaciones de la Universidad de Murcia. Su trabajo de
investigación se desarrolla en el ámbito de las aplicaciones
distribuidas aplicadas a la tele-enseñanza, incluyendo XML,
CORBA, y QoS en aplicaciones de transmisión de datos
multimedia.
Gregorio Martínez Pérez
recibió el título de Ingeniero en
Informática en la Universidad de Murcia. En 1997 comenzó a
trabajar en el Servicio de Informática de la misma Universidad
en diversos proyectos relacionados con la seguridad en las
comunicaciones. En 1999, comenzó como personal investiga-
dor en el Departamento de Ingeniería de la Información y las
Comunicaciones de la Universidad de Murcia, pasando a ser
profesor del mismo departamento en el año 2001. Su actividad
investigadora está centrada a las infrastructuras de seguridad,
las tarjetas inteligentes, los sistemas de control de acceso y a la
nueva versión del protocolo IPv6, temas en los cuales ha
trabajado y lo sigue haciendo a través de diferentes proyectos
nacionales e internacionales. Además tiene varias publicacio-
nes en conferencias y revistas de carácter nacional e internacio-
nal.
documento XML, y puede además ser aplicada simultánea-
mente a varios contenidos de datos.
A la hora de firmar datos XML se nos presenta un problema.
La gran flexibilidad de XML nos permite expresar la misma
información de múltiples formas: podemos tener dos docu-
mentos XML lógicamente equivalentes, pero con pequeñas
diferencias entre ellos, como pueden ser los delimitadores de
fin de línea, los espacios en blanco dentro de una etiqueta,
los comentarios, etc. No en vano, las aplicaciones XML
tienden a tomarse libertades con cambios de este tipo, que no

Page 25
NOVATICA/UPGRADE jul./ago. 2002 nº158
28 Edición digital/ ©ATI 2002
tienen ningún impacto en el contenido de la información,
pero sí lo tienen a efectos de la firma digital, pues, como ya
sabemos, los cálculos de verificación de una firma se tienen
que realizar exactamente sobre los mismos bytes que los
cálculos de generación de la misma. Para solucionar este
problema se introduce el concepto de forma canónica de un
documento XML [3]. El paso a forma canónica de un
documento XML consiste en aplicar sobre él una serie de
transformaciones para expresar de forma estándar la infor-
mación que puede cambiar en él. De esta manera, dos
documentos que tengan la misma forma canónica se van a
considerar lógicamente equivalentes.En otro orden de cosas,
es importante destacar que nos podemos encontrar con distin-
tos tipos de firmas XML. En este sentido, si la firma XML
contiene al objeto firmado se dice que es envolvente (
enveloping
),
si está contenida en el objeto firmado se dice que es envuelta
(
enveloped
), y si es externa al objeto firmado, se dice que es
independiente (
detached
).
Mirando todo esto desde un punto de vista práctico, para
aplicar una firma XML a un contenido digital arbitrario se
genera, en primer lugar, el resumen digital de cada objeto de
datos que se quiere firmar; a continuación se deposita el
valor resultante en un elemento XML, junto con otra infor-
mación que luego detallaremos, y finalmente se genera el
resumen digital del elemento anteriormente citado y se
firma. De esta manera, el proceso inverso de validación
conllevará a su vez dos pasos: en primer lugar se realizará
la validación de la firma, que nos asegura la integridad de
los resúmenes digitales de los objetos de datos, y,a continua-
ción, se realizará la validación de cada uno de los resúmenes
digitales de los objetos de datos propiamente dichos. La
validez de cada resumen nos asegurará la integridad del
objeto de datos correspondiente. Una firma XML se represen-
ta por medio del elemento
Signature
, cuya estructura general se
muestra en la
figura 1
. En la notación utilizada «?» indica cero
o una ocurrencia, «+» indica una o más ocurrencias y «*»
indica cero o más ocurrencias.
<Signature ID?>
<SignedInfo>
<CanonicalizationMethod/>
<SignatureMethod/>
(<Reference URI? >
<Transforms>)?
<DigestMethod>
<DigestValue>
</Reference>)+
</SignedInfo>
<SignatureValue>
(<KeyInfo>)?
(<Object ID?>)*
</Signature>
Figura 1. Estructura general de un elemento
Signature
Como podemos observar, el elemento
Signature
contiene
cuatro elementos:
SignedInfo
,
SignatureValue
,
KeyInfo
y
Object
. El elemento
SignedInfo
es el que realmente se firma;
dicho elemento contiene también información sobre los
algoritmos de canonización y de firma usados para obtener
el contenido del elemento
SignatureValue
.
SignedInfo
tam-
bién contiene un elemento
Reference
para cada uno de los
objetos firmados, en el que tenemos una referencia al objeto
de datos (a través de una
URI
), el método que se utiliza para
calcular el resumen digital del objeto y el resumen digital
propiamente dicho. Un elemento
Reference
también puede
incluir transformaciones que, una vez aplicadas al objeto de
datos referenciado, producen la entrada a la operación de
resumen digital (como podría ser por ejemplo la canoniza-
ción para el caso de datos XML).
Por su parte, el elemento
KeyInfo
indica la clave que va a ser
usada para validar la firma, pudiendo contener claves,
nombres de claves, certificados u otra información. Por
último, el elemento
Object
se utiliza para incluir objetos de
datos arbitrarios dentro del elemento
Signature
, que pueden
o no ser firmados. La
figura 2
muestra un ejemplo sencillo
de firma de un documento XML.
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/
TR/2001/REC-xml-c14n-20010315"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/
09/xmldsig#dsa-sha1"/>
<Reference URI="http://www.um.es/midocumento/">
<Transforms>
<Transform Algorithm="http://www.w3.org/TR/
2001/REC-xml-c14n-20010315"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/
09/
xmldsig#sha1"/>
<DigestValue>j6lwx3rvEPO0vKtMup4N</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
<KeyInfo>
<KeyValue>
<DSAKeyValue>
<P>...</P><Q>...</Q><G>...</G><Y>...</Y>
</DSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
Figura 2. Ejemplo de firma de un documento XML
3. El cifrado digital con XML
Al igual que la firma, el cifrado en XML [2] puede aplicarse
a datos arbitrarios, a un documento XML completo, a un
elemento XML o al contenido de un elemento XML. El
resultado de aplicar el cifrado XML es un elemento de tipo
EncryptedData
, que contiene, a través de uno de sus elemen-
tos hijos, o identifica, a través de una referencia, los datos
cifrados. Si lo que ciframos es un elemento XML o el
contenido de un elemento,
EncryptedData
reemplaza al
elemento o al contenido, respectivamente, en la versión
cifrada de dicho documento XML. La
figura 3
muestra la
estructura del elemento
EncryptedData
.
<EncryptedData Id? Type?>
<EncryptionMethod/>?
<ds:KeyInfo>
<EncryptedKey>?
<AgreementMethod>?
<ds:KeyName>?
<ds:RetrievaMethod>?
<ds:*>?
</ds:KeyInfo>?
<CipherData>
<CipherValue>?
<CipherReference URI?>?
</CipherData>
<EncryptionProperties>?
</EncryptedData>
Figura 3. Estructura general de un elemento
ExcryptedData
Como podemos observar,
EncryptedData
contiene cuatro
elementos. El primero de ellos
EncryptionMethod
indica el
algoritmo de cifrado usado, mientras que el segundo, el
elemento
ds:KeyInfo
proporciona o identifica la clave em-
pleada para cifrar los datos. Por su parte,
CipherData
contiene los datos cifrados o bien una referencia al lugar
dónde se encuentran, y, por último, el elemento
EncryptionProperties
proporciona de manera opcional otra
información sobre la generación de los datos cifrados, como
puede ser el caso de marcas de tiempo o
time-stamping
.

Page 26
NOVATICA/UPGRADE jul../ago. 2002 nº158
Edición digital/ ©ATI 2002 29
Figura 5. Formato de un mensaje SOAP, e interacción básica con ebXML
Entrando un poco más en detalle, los elementos
EncryptionMethod
y
ds:KeyInfo
son opcionales, ya que
tanto el algoritmo de cifrado como la clave pueden haber
sido acordados previamente entre el emisor y el receptor. Por
su parte,
ds:KeyInfo
es un elemento similar al definido en la
especificación de la firma XML, vista en el apartado ante-
rior. Como tal, ofrece distintas formas de proporcionar la
clave de cifrado, ya sea cifrada, a través del elemento
EncryptedKey
, o bien usando negociación de claves --como
Diffie-Hellman-- a través del elemento
AgreementMethod;
otras alternativas pueden ser la de proporcionar el
identificador de una clave conocida a través del elemento
ds:KeyName
, o una referencia al lugar en el que está
almacenada la clave --como en los sistemas DNSsec--
mediante el elemento
ds:RetrievalMethod.
En la
figura 4
, aparece un ejemplo sencillo de cifrado de un
elemento con una clave simétrica. En el documento XML, el
elemento en claro es sustituido por la etiqueta
EncryptedData
.
Observamos que, mediante el atributo
Type
,
se indica que los
datos cifrados corresponden a un elemento XML. El algoritmo
utilizado es el 3DES-CBC y se ha utilizado una clave simétrica
cuyo nombre es «Mi Clave» para realizar el cifrado. El
elemento
CipherData
contiene la secuencia de octetos cifrada
codificada en Base64 dentro de
CipherValue
.
<EncryptedData xmlns='http://www.w3.org/2001/04/
xmlenc#'
type='http://www.w3.org/2001/04/xmlenc#Element'/>
<EncryptionMethod Algorithm='http://www.w3.org/
2001/04/xmlenc#3des-cbc'/>
<ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/
xmldsig#'>
<ds:KeyName>Mi Clave</ds:KeyName>
</ds:KeyInfo>
<CipherData>
<CipherValue>DEADBEEF</CipherValue>
</CipherData>
</EncryptedData>
Figura 4. Ejemplo de cifrado de un documento XML
4. La combinación de la firma digital y el cifrado
con XML
La aplicación de ambos, cifrado y firma, sobre porciones de un
documento XML puede provocar que sea difícil realizar posterior-
mente el descifrado y la verificación de la firma. En particular, al
verificar una firma debemos saber si la firma fue computada sobre
la representación cifrada o no cifrada de los elementos. Si se realizan
operaciones de cifrado sobre parte de un contenido ya firmado, será
necesario, antes de verificar la firma, descifrar las porciones que se
cifraron después de firmar. Para indicar el orden adecuado de
descifrado y validación cuando se combina la firma y el cifrado, se
introduce una nueva transformación en la firma XML [4], denomi-
nada
transformación de descifrado
. Esta transformación toma
como parámetro una lista de referencias a porciones que fueron
cifradas antes de realizar la firma. De esta manera, cuando el receptor
encuentra una transformación de descifrado en una firma, descifrará
todos los contenidos cifrados del documento excepto aquellos que
se indiquen en la lista de referencias contenidas en la transformación.
5. ebXML
Una de las iniciativas más interesantes de desarrollo de un
estándar de comercio electrónico que emplea el estándar de
firma XML es ebXML [ebXML], propuesta por OASIS y
UN/CEFACT. ebXML emplea SOAP (
Simple Object Access
Protocol
) [6] en el subsistema de mensajería. SOAP es un
estándar del W3C que define el empaquetado de mensajes
basado en XML; los mensajes son transportados con proto-
colos como HTTP o SMTP, haciendo uso de tipos MIME que
los identifican adecuadamente. La
figura 5
muestra la
estructura XML de un mensaje SOAP.
Dejando muchos detalles al margen, la interacción entre las
empresas se basa en el empleo de un registro central que actúa
como un directorio. Las empresas sitúan en el registro ebXML
un documento XML denominado
Collaboration Protocol