XML para el principiante absoluto

HTML y la World Wide Web están en todas partes. Como ejemplo de su ubicuidad, voy a ir a Centroamérica para Semana Santa este año y, si quiero, podré navegar por la Web, leer mi correo electrónico e incluso realizar operaciones bancarias en línea desde cibercafés en Antigua Guatemala y Ciudad de Belice. (Sin embargo, no tengo la intención de hacerlo, ya que hacerlo me quitaría un tiempo de una cita que tengo con una palmera y un coco relleno de ron).

Y, sin embargo, a pesar de la omnipresencia y popularidad de HTML, está muy limitado en lo que puede hacer. Está bien para difundir documentos informales, pero HTML ahora se usa para hacer cosas para las que nunca fue diseñado. Intentar diseñar sistemas de datos interoperables, flexibles y de alta resistencia a partir de HTML es como intentar construir un portaaviones con sierras para metales y soldadores: las herramientas (HTML y HTTP) simplemente no están a la altura del trabajo.

La buena noticia es que muchas de las limitaciones de HTML se han superado en XML, el Extensible Markup Language. XML es fácilmente comprensible para cualquiera que entienda HTML, pero es mucho más poderoso. Más que un simple lenguaje de marcado, XML es un metalenguaje , un lenguaje que se utiliza para definir nuevos lenguajes de marcado. Con XML, puede crear un lenguaje diseñado específicamente para su aplicación o dominio.

XML complementará, en lugar de reemplazar, HTML. Mientras que HTML se utiliza para formatear y mostrar datos, XML representa el significado contextual de los datos.

Este artículo presentará la historia de los lenguajes de marcado y cómo surgió XML. Examinaremos datos de muestra en HTML y pasaremos gradualmente a XML, demostrando por qué proporciona una forma superior de representar datos. Exploraremos las razones por las que podría necesitar inventar un lenguaje de marcado personalizado y le enseñaré cómo hacerlo. Cubriremos los conceptos básicos de la notación XML y cómo mostrar XML con dos tipos diferentes de lenguajes de estilo. Luego, nos sumergiremos en el Modelo de objetos de documento, una poderosa herramienta para manipular documentos como objetos (o manipular estructuras de objetos como documentos, dependiendo de cómo se mire). Repasaremos cómo escribir programas Java que extraigan información de documentos XML, con un puntero a un programa gratuito útil para experimentar con estos nuevos conceptos. Finalmente nosotros'Echemos un vistazo a una empresa de Internet que basa su estrategia tecnológica central en XML y Java.

¿XML es para ti?

Aunque este artículo está escrito para cualquier persona interesada en XML, tiene una relación especial con la serie JavaWorld sobre XML JavaBeans. (Consulte Recursos para obtener enlaces a artículos relacionados). Si ha estado leyendo esa serie y no lo está "entendiendo", este artículo debería aclarar cómo usar XML con beans. Si lo está obteniendo, este artículo sirve como el complemento perfecto para la serie XML JavaBeans, ya que cubre temas que no se tratan allí. Y, si es uno de los pocos afortunados que todavía tiene los artículos XML JavaBeans que esperar, le recomiendo que lea el presente artículo primero como material introductorio.

Una nota sobre Java

Hay tanta actividad XML reciente en el mundo de la informática que incluso un artículo de esta longitud sólo puede rozar la superficie. Aún así, el objetivo de este artículo es brindarle el contexto que necesita para usar XML en los diseños de su programa Java. Este artículo también cubre cómo funciona XML con la tecnología web existente, ya que muchos programadores de Java trabajan en ese entorno.

XML abre la programación de Internet y Java a funciones portátiles que no son de navegador. XML libera el contenido de Internet del navegador de la misma manera que Java libera el comportamiento del programa de la plataforma. XML hace que el contenido de Internet esté disponible para aplicaciones reales.

Java es una plataforma excelente para usar XML y XML es una excelente representación de datos para aplicaciones Java. Señalaré algunas de las fortalezas de Java con XML a medida que avanzamos.

Comencemos con una lección de historia.

Los orígenes de los lenguajes de marcado

El HTML que todos conocemos y amamos (bueno, lo sabemos, de todos modos) fue diseñado originalmente por Tim Berners-Lee en el CERN ( le Conseil Européen pour la Recherche Nucléaire, o el Laboratorio Europeo de Física de Partículas) en Ginebra para permitir a los nerds de la física ( e incluso no nerds) para comunicarse entre sí. HTML se lanzó en diciembre de 1990 dentro del CERN y se puso a disposición del público en el verano de 1991 para el resto de nosotros. El CERN y Berners-Lee entregaron las especificaciones para HTML, HTTP y URL, en la antigua tradición de compartir y disfrutar en Internet.

Berners-Lee definió HTML en SGML, el lenguaje de marcado estándar generalizado. SGML, como XML, es un metalenguaje, un lenguaje utilizado para definir otros lenguajes. Cada lenguaje así definido se denomina una aplicación de SGML. HTML es una aplicación de SGML.

SGML surgió de una investigación realizada principalmente en IBM sobre la representación de documentos de texto a finales de los sesenta. IBM creó GML ("General Markup Language"), un lenguaje predecesor de SGML, y en 1978 el American National Standards Institute (ANSI) creó su primera versión de SGML. El primer estándar fue lanzado en 1983, con el borrador del estándar lanzado en 1985, y el primer estándar fue publicado en 1986. Curiosamente, el primer estándar SGML se publicó usando un sistema SGML desarrollado por Anders Berglund en el CERN, la organización que, como que hemos visto, nos dio HTML y la Web.

SGML se utiliza ampliamente en grandes industrias y gobiernos, como grandes empresas aeroespaciales, automotrices y de telecomunicaciones. SGML se utiliza como documento estándar en el Departamento de Defensa de los Estados Unidos y el Servicio de Impuestos Internos. (Para los lectores fuera de los EE. UU., El IRS son los encargados de los impuestos).

Albert Einstein dijo que todo debería ser lo más simple posible y no más simple. La razón por la que SGML no se encuentra en más lugares es que es extremadamente sofisticado y complejo. Y HTML, que puede encontrar en todas partes, es muy simple; para muchas aplicaciones, es demasiado simple.

HTML: toda forma y sin sustancia

HTML es un lenguaje diseñado para "hablar sobre" documentos: encabezados, títulos, leyendas, fuentes, etc. Está muy orientado a la estructura y presentación de documentos.

Es cierto que los artistas y los piratas informáticos han podido hacer milagros con la herramienta relativamente aburrida llamada HTML. Pero HTML tiene serios inconvenientes que lo hacen inadecuado para diseñar sistemas de información flexibles, poderosos y evolutivos. Aquí algunas de las principales quejas:

  • HTML no es extensible

    Un lenguaje de marcado extensible permitiría a los desarrolladores de aplicaciones definir etiquetas personalizadas para situaciones específicas de la aplicación. A menos que sea un gorila de 600 libras (y tal vez ni siquiera entonces), no puede exigir a todos los fabricantes de navegadores que implementen todas las etiquetas de marcado necesarias para su aplicación. Por lo tanto, está atascado con lo que los grandes fabricantes de navegadores o el W3C (World Wide Web Consortium) le permitirán tener. Lo que necesitamos es un lenguaje que nos permita crear nuestras propias etiquetas de marcado sin tener que llamar al fabricante del navegador.

  • HTML está muy centrado en la visualización

    HTML es un buen lenguaje para fines de visualización, a menos que requiera mucho formato preciso o control de transformación (en cuyo caso apesta). HTML representa una mezcla de estructura lógica del documento (títulos, párrafos y demás) con etiquetas de presentación (negrita, alineación de imágenes, etc.). Dado que casi todas las etiquetas HTML tienen que ver con cómo mostrar información en un navegador, HTML es inútil para otras aplicaciones de red comunes, como la replicación de datos o los servicios de aplicaciones. Necesitamos una forma de unificar estas funciones comunes con la pantalla, por lo que el mismo servidor utilizado para examinar los datos también puede, por ejemplo, realizar funciones empresariales e interoperar con sistemas heredados.

  • HTML no suele ser reutilizable directamente

    Creating documents in word-processors and then exporting them as HTML is somewhat automated but still requires, at the very least, some tweaking of the output in order to achieve acceptable results. If the data from which the document was produced change, the entire HTML translation needs to be redone. Web sites that show the current weather around the globe, around the clock, usually handle this automatic reformatting very well. The content and the presentation style of the document are separated, because the system designers understand that their content (the temperatures, forecasts, and so on) changes constantly. What we need is a way to specify data presentation in terms of structure, so that when data are updated, the formatting can be "reapplied" consistently and easily.

  • HTML only provides one 'view' of data

    It's difficult to write HTML that displays the same data in different ways based on user requests. Dynamic HTML is a start, but it requires an enormous amount of scripting and isn't a general solution to this problem. (Dynamic HTML is discussed in more detail below.) What we need is a way to get all the information we may want to browse at once, and look at it in various ways on the client.

  • HTML has little or no semantic structure

    Most Web applications would benefit from an ability to represent data by meaning rather than by layout. For example, it can be very difficult to find what you're looking for on the Internet, because there's no indication of the meaning of the data in HTML files (aside from META tags, which are usually misleading). Type

    red

    into a search engine, and you'll get links to Red Skelton, red herring, red snapper, the red scare, Red Letter Day, and probably a page or two of "Books I've Red." HTML has no way to specify what a particular page item means. A more useful markup language would represent information in terms of its meaning. What we need is a language that tells us not how to

    display

    information, but rather, what a given block of information

    is

    so we know what to do with it.

SGML has none of these weaknesses, but in order to be general, it's hair-tearingly complex (at least in its complete form). The language used to format SGML (its "style language"), called DSSSL (Document Style Semantics and Specification Language), is extremely powerful but difficult to use. How do we get a language that's roughly as easy to use as HTML but has most of the power of SGML?

Origins of XML

As the Web exploded in popularity and people all over the world began learning about HTML, they fairly quickly started running into the limitations outlined above. Heavy-metal SGML wonks, who had been working with SGML for years in relative obscurity, suddenly found that everyday people had some understanding of the concept of markup (that is, HTML). SGML experts began to consider the possibility of using SGML on the Web directly, instead of using just one application of it (again, HTML). At the same time, they knew that SGML, while powerful, was simply too complex for most people to use.

In the summer of 1996, Jon Bosak (currently online information technology architect at Sun Microsystems) convinced the W3C to let him form a committee on using SGML on the Web. He created a high-powered team of muckety-mucks from the SGML world. By November of that year, these folks had created the beginnings of a simplified form of SGML that incorporated tried-and-true features of SGML but with reduced complexity. This was, and is, XML.

In March 1997, Bosak released his landmark paper, "XML, Java and the Future of the Web" (see Resources). Now, two years later (a very long time in the life of the Web), Bosak's short paper is still a good, if dated, introduction to why using XML is such an excellent idea.

SGML was created for general document structuring, and HTML was created as an application of SGML for Web documents. XML is a simplification of SGML for general Web use.

An XML conceptual example

All this talk of "inventing your own tags" is pretty foggy: What kind of tags would a developer want to invent and how would the resulting XML be used? In this section, we'll go over an example that compares and contrasts information representation in HTML and XML. In a later section ("XSL: I like your style") we'll go over XML display.

First, we'll take an example of a recipe, and display it as one possible HTML document. Then, we'll redo the example in XML and discuss what that buys us.

HTML example

Take a look at the little chunk of HTML in Listing 1:

   Lime Jello Marshmallow Cottage Cheese Surprise   

Lime Jello Marshmallow Cottage Cheese Surprise

My grandma's favorite (may she rest in peace).

Ingredients

Qty Units Item
1 box lime gelatin
500 g multicolored tiny marshmallows
500 ml cottage cheese
dash Tabasco sauce (optional)

Instructions

  1. Prepare lime gelatin according to package instructions...

Listing 1. Some HTML

(A printable version of this listing can be found at example.html.)

Looking at the HTML code in Listing 1, it's probably clear to just about anyone that this is a recipe for something (something awful, but a recipe nonetheless). In a browser, our HTML produces something like this:

Lime Jello Marshmallow Cottage Cheese Surprise

My grandma's favorite (may she rest in peace).

Ingredients

Qty Units Item
1 box lime gelatin
500 g multicolored tiny marshmallows
500 ml Cottage cheese
  dash Tabasco sauce (optional)

Instructions

  1. Prepare lime gelatin according to package instructions...

Listing 2. What the HTML in Listing 1 looks like in a browser

Now, there are a number of advantages to representing this recipe in HTML, as follows:

  • It's fairly readable. The markup may be a little cryptic, but if it's laid out properly it's pretty easy to follow.

  • The HTML can be displayed by just about any HTML browser, even one without graphics capability. That's an important point: The display is browser-independent. If there were a photo of the results of making this recipe (and one certainly hopes there isn't), it would show up in a graphical browser but not in a text browser.

  • You could use a cascading style sheet (CSS -- we'll talk a bit about those below) for general control over formatting.

There's one major problem with HTML as a data format, however. The meaning of the various pieces of data in the document is lost. It's really hard to take general HTML and figure out what the data in the HTML mean. The fact that there's an of this recipe with a (quantity) of 500 ml () of cottage cheese would be very hard to extract from this document in a way that's generally meaningful.

Now, the idea of data in an HTML document meaning something may be a bit hard to grasp. Web pages are fine for the human reader, but if a program is going to process a document, it requires unambiguous definitions of what the tags mean. For instance, the tag in an HTML document encloses the title of the document. That's what the tag means, and it doesn't mean anything else. Similarly, an HTML tag means "table row," but that's of little use if your program is trying to read recipes in order to, say, create a shopping list. How could a program find a list of ingredients from a Web page formatted in HTML?

Sure, you could write a program that grabs the headers out of the document, reads the table column headers, figures out the quantities and units of each ingredient, and so on. The problem is, everyone formats recipes differently. What if you're trying to get this information from, say, the Julia Childs Web site, and she keeps messing around with the formatting? If Julia changes the order of the columns or stops using tables, she'll break your program! (Though it has to be said: If Julia starts publishing recipes like this, she may want to think about changing careers.)

Now, imagine that this recipe page came from data in a database and you'd like to be able to ship this data around. Maybe you'd like to add it to your huge recipe database at home, where you can search and use it however you like. Unfortunately, your input is HTML, so you'll need a program that can read this HTML, figure out what all the "Ingredients," "Instructions," "Units," and so forth are, and then import them to your database. That's a lot of work. Especially since all of that semantic information -- again, the meaning of the data -- existed in that original database but were obscured in the process of being transformed into HTML.

Now, imagine you could invent your own custom language for describing recipes. Instead of describing how the recipe was to be displayed, you'd describe the information structure in the recipe: how each piece of information would relate to the other pieces.

XML example

Let's just make up a markup language for describing recipes, and rewrite our recipe in that language, as in Listing 3.

  Lime Jello Marshmallow Cottage Cheese Surprise  My grandma's favorite (may she rest in peace).    1 lime gelatin   500 multicolored tiny marshmallows   500 Cottage cheese    Tabasco sauce     Prepare lime gelatin according to package instructions     

Listing 3. A custom markup language for recipes

It will come as little surprise to you, being the astute reader you are, that this recipe in its new format is actually an XML document. Maybe the fact that the file started with the odd header


  

gave it away; in fact, every XML file should begin with this header. We've simply invented markup tags that have a particular meaning; for example, "An is a (quantity in specified units) of a single , which is possibly optional." Our XML document describes the information in the recipe in terms of recipes, instead of in terms of how to display the recipe (as in HTML). The semantics, or meaning of the information, is maintained in XML because that's what the tag set was designed to do.

Notes on notation

It's important to get some nomenclature straight. In Figure 1, you see a start tag, which begins an enclosed area of text, known as an Item, according to the tag name. As in HTML, XML tags may include a list of attributes (consisting of an attribute name and an attribute value.) The Item defined by the tag ends with the end tag.

Not every tag encloses text. In HTML, the

tag means "line break" and contains no text. In XML, such elements aren't allowed. Instead, XML has empty tags, denoted by a slash before the final right-angle bracket in the tag. Figure 2 shows an empty tag from our XML recipe. Note that empty tags may have attributes. This empty tag example is standard XML shorthand for .

In addition to these notational differences from HTML, the structural rules of XML are more strict. Every XML document must be well-formed. What does that mean? Read on!

Ooh-la-la! Well-formed XML

The concept of well-formedness comes from mathematics: It's possible to write mathematical expressions that don't mean anything. For example, the expression

2 ( + + 5 (=) 9 > 7

looks (sort of) like math, but it isn't math because it doesn't follow the notational and structural rules for a mathematical expression (not on this planet, at least). In other words, the "expression" above isn't well-formed. Mathematical expressions must be well-formed before you can do anything useful with them, because expressions that aren't well-formed are meaningless.

A well-formed XML document is simply one that follows all of the notational and structural rules for XML. Programs that intend to process XML should reject any input XML that doesn't follow the rules for being well-formed. The most important of these rules are as follows: