Por Manuel G. Noriega

Jeremy Keith es un tío listo. Gracias en parte a su dominio de la programación en Javascript, ha podido crear Adactio Elsewhere, dónde recopila fotos, enlaces y eventos en su propio nudo central de información. La tarea de Jeremy se ha visto enormemente facilitada por cosas como la proliferación de las tecnologías de sindicación de contenidos y de APIs, un mecanismo fácil de recuperar información, en los distintos servicios web.

Con esfuerzos como este vamos llegando a lo que se llama la Web 2.0, un pasito más hacia las promesas de la web semántica. Antes la web estaba hecho de “sitios”, que “visitabamos”, hacia donde “navegábamos”. Ahora, la web va cada vez más hacia una serie de servicios. Antes queriamos sitios y llegabamos a ellos a traves de los navegadores. Ahora queremos información y llegamos a ella a través de los sitios. El sitio ha pasado de ser el recurso a ser el interfaz.

Este ha sido un proceso azaroso y como todas las cosas interesantes tiene detrás una historia llena de desarrollos e imprevistos. Y cómo las noticias de última hora, está ahora mismo desarrollándose delante de nuestros ojos.

El fluido vital de la web son los lenguajes de marcado que se usan para crear las páginas que conforman los sitios. Probablemente hayas oido hablar de HTML. Es solo un conjunto de elementos (también llamados etiquetas) que crean la multitud de diferencias entre un documento web y un documento en texto plano. A utilizar determinados elementos HTML para acompañar o “vestir” determinado texto se lo conoce como “marcar” el texto. Un agente de usuario, un navegador, es un intérprete que traduce muy deprisa esas marcas a otro tipo de símbolos: una imagen, una negrita, una tabla, un determinado tono de voz…

Esta, en cierta manera engañosa, sencillez de uso de los lenguajes de marcado, junto la explosión demográfica de la web causó una espiral de problemas y una degeneración en la calidad del código utilizado. Visto en retrospectiva es un proceso natural, lo que no quiere decir óptimo: descubrimos un juguete nuevo y brillante y nos lanzamos sobre él con más ganas de toquetear que de leer el manual de instrucciones.

¿Quién se podía parar a meditar sobre las implicaciones a largo plazo cuándo acabas de descubrir que con un simple elemento “blink” puedes crear un aparente y vistoso efecto en pantalla? Mi texto parpadea, mi texto tiene efectos especiales, mi texto está vivo, mi texto se puede leer en Mozambique o en Hong Kong. Sírvete una copa y pásame una a mí. Ya.

Sin embargo, como todas las buenas borracheras, no tardaron en aparecer los síntomas de una devastadora resaca. Y como en todas las borracheras realmente memorables, descubrimos que habiamos cometido un tremendo error. Un error que roncaba sonoramente a nuestro lado.

Verás, para empezar el objetivo de todo este tinglado era la universalidad, la promesa de ‘escribe una vez / lée en cualquier parte”. Usa un determinado elemento (etiqueta) y estáte seguro de que lo que has querido decir será transportado más o menos indenme a través de todos los canales y dispositivos que acepten HTML.

Ese era el Sueño. Entonces llegaron las tentaciones fáciles. Los principales navegadores empezaron a desarrollar sus propias innovaciones, sus propios especiales sabores, que ofrecían satisfacción inmmediata a cambio de una pequeña traición al Sueño: las innovaciones eran propias de cada navegador, no parte del estándard HTML, así que sólo funcionarían en ese parque de navegadores. Mucha gente, la inmensa mayoría aceptó el trato. Y surgieron más elementos exclusivos de un navegador, “elementos propietarios”, que eran utilizados como arma competitiva por los navegadores para conseguir más cuota de mercado. Las apuestas subían. Netscape veía el “marquee” (etiqueta que permite un texto deslizante o marquesina) de Microsoft y subía con un “blink” (texto que parpadeaba). Todos ganábamos, todos perdíamos aunque no nos dabamos cuenta, claro. Estábamos como cubas.

Las consecuencias de estas famosas (infames) guerras de navegadores, este maremagnum de etiquetas propietarias fueron las conocidas webs optimizadas para una navegador concreto, especímenes que proliferaron y durante un tiempo parecieron hacer inevitable la balcanización de la web, fragméntandola en feudos aislados y esclavos de un determinado navegador.

En cierto momento se llegó a un extremo que ponía en peligro no solo la evolución, sino la misma existencia de la WWW como plataforma con algún viso de universalidad y legitimidad.

Afortunadamente ahora nos encontramos en el medio de una estapa de renovación, lenta y dificil pero segura y de avance constante. Es el enfoque basado en los estándares web, que se concreta en la normalización de páginas y herramientas de desarrollo en torno a las recomendaciones del W3C, que se encarga de elaborar, depurar y publicar las “biblias” oficiales de la miriada de tecnologías disponibles.

Esta normalización o compromiso de desarrollo se manifiesta en dos niveles: la validación automática, que asegura el cumplimiento de la “letra de la ley” en cuanto al uso ajustado a sintaxis de los elementos bendecidos por el W3C y el marcado semántico, que busca las soluciones de marcado que resuelvan de la forma más fiel, eficiente y elegante la tarea de expresar mediante elementos HTML los distintos significados y estructuras implícitas en los textos del lenguaje natural.

Es decir, la validación de nuestros documentos nos asegura que los elementos usados pertenecen a las recomendaciones W3C y su sintaxis es la adecuada.

El marcado semántico trata el mucho más elusivo problema de cuándo, dónde y porqué utilizar o dejar de utilizar cada elemento.

Marcado semántico y microformatos

Las discusiones y las investigaciones sobre marcado semántico se prodigan en multitud de blogs y foros, bajo muchas formas y en muchos idiomas, pero de la observación de estas conversaciones se observa una pauta constante de progresivo descubrimiento de soluciones óptimas y de consenso a determinados problemas con los cuales se enfrenta un desarrollador web.

¿Cómo marcar un menú de navegación? ¿Una fecha? ¿Qué elementos HTML debo usar para estructurar un fragmento de poesía? Las respuestas y cavilaciones sobre este tipo de sutilezas han cristalizado en la aparición de microformatos, descripciones formalizadas de las mejores prácticas para un problema de marcado determinado.

Son “formatos” porque se publican con afán de estandarización, de aceptación y de establecerse como solución comunmente aceptada. Son “micro” tanto por la poca documentación necesaria para establecerlos y definirlos con precisión, como por aplicarse a problemas de muy poca extensión. Pretenden explicar exhaustivamente una pregunta concreta, no dar un juego completo de herramientas al desarrollador.

Son “micro” también porque siempre son fragementos de código HTML/XHTML, con lo cual se convierten en pequeñas piezas reutilizables y apropiadas para su engarce en páginas web completas, válidas y semánticas.

La utilidad puede ser doble: a un nivel “egoista”, considerando solo una página o un sitio, aseguran al desarrollador el estar adoptando la mejor práctica disponible con las herramientas de su profesión y el poder adoptar de forma total y completa el desarrollo según estándares con todos los beneficios ya de sobra conocidos.

Sin embargo las cosas realmente interesante aparecen cuando consideramos “a vista de pájaro” las implicaciones de un ecosistema de páginas con fragmentos empotrados de código “microformateado”. Si 100, 1.000 o 1.000.000 de páginas ofrecen la posibilidad de ser recuperadas y procesadas con resultados predecibles, podemos empezar a imaginar servicios sin barreras de entrada que almacenen y compartan información de distintas páginas. “Agentes” que analizen de forma eficaz la información para extraer significados.

Parece extraño, pero pasa todos los días millones de veces y se puede ver un ejemplo en los registros de cualquier servidor web: estos agentes pueden ser simplemente los bots de búsqueda. Está al alcance de cualquiera con ciertas nociones de programación desarrollar su propio robot que recorra páginas y analizando la información insertada en su código HTML. Y si sabe qué buscar, qué microformato contiene la información que necesita, será una tarea casi trivial extraerla y recopilarla.

hReview es un microformato para codificar las opiniones un determinado recurso o producto tan frecuente en cualquier tienda online. Puedes usarlo en tu próximo desarrollo de un sitio así. Basándonos en la predictibilidad que dá la convención, el formato, no es dificil desarrollar un servicio que recopile todas las críticas sobre algo concreto disponible en tiendas, foros, blogs. Alguien puede echarle encima un motor de búsqueda. Ahora tienes un buscador inteligente que comprende que busca opiniones y sabe que lo que se expresa en hReview, quiere decir algo sobre algo.

Esto puede resultar familiar a muchos porque es una de las promesas de la Web Semántica. Vemos que el proceso evolutivo que agrupa estándares, marcado semántico y microformatos está desembocando por tanto en la realización de alguno de los objetivos a largo plazo y más primordiales para los teóricos de la red, aunque se llega a estos objetivos desde un enfoque de “abajo-arriba”, que prima los intereses prácticos y la extensión por evolución de las tecnologías existentes, en vez del enfoque de “arriba-abajo” que da más importancia a la introducción revolucionaria de nuevas tecnologías.

Esto son en definitiva, los microformatos, la destilación del saber hacer cotidiano de miles de “tejedores de la web”, documentada y formalizada hasta cierto punto. Cualquiera puede proponer un microformato y someterlo a la crítica de la comunidad relevante y al examen definitivo de la utilidad práctica en determinados escenarios. Los mejores sobrevivirán.

Sobre el texto plano extendemos la fina tela de los lenguajes de marcado. Sobre estos aparecen, como copos de nieve, las estructuras repetitivas del marcado semántico y de forma natural, casi por deducción aparecen los microformatos.

Y al lado de estos, otros órganos que crecen imparablemente: los feeds, las APIs. Las membranas que apresan los datos dentro de los sitios se vuelven cada vez más porosas y aparecen cilios y mecanismos de comunicación entre sitios, entre servicios, entre software.

Fluyen nuestras fotos, nuestros posts, nuestros libros, nuestros enlaces, nuestros objetivos. En el pasado están las webs pre-estándares y las guerras de navegadores; en el presente está el camino a la web 2.0 y los intentos fallidos, las pequeñas miserias. ¿Y el futuro? El futuro ya está aquí, sólo que no está distribuido uniformemente.

Muchas gracias a Eduardo Manchón por su infinita paciencia conmigo mientras esperaba este artículo y sus sugerencias para que evitar que se convirtiera en un completo desastre.

que permite hacer consultas XPath a archivos XML.

Supongamos el siguiente archivo XML, al cual llamaremos libro.xml:

Consultas

Obtener el título del libro:

Obtener el capítulo 1:

Obtener el capítulo 2:

Obtener el capítulo 2 usando last():

Obtener la sección 1 del capítulo 2:

Obtener los párrafos que contienen algún atributo:

Obtener los párrafos no destacados del capítulo 1:

Parámetros

Sitio oficial: XMLStarlet Command Line XML Toolkit

El 26 de Febrero de 1991, Tim Berners Lee presentaba WorldWideWeb (posteriormente renombrado a Nexus), un programa para la estación de trabajo Next que implementaba el primer navegador web del mundo.

Imagen tomada de Wikipedia

Durante los años 80, mientras trabajaba como físico en el CERN, Tim Berners Lee concibió un sistema de intercambio de información científica construido sobre el concepto de hiperenlace; es decir,  un sistema en el que cada documento incluyera referencias (enlaces) a otros. Su idea se materializó bajo dos componentes, por un lado estaba HTTP, que era el protocolo utilizado por el programa de navegación para pedir los documentos al servidor, y por otro lado estaba HTML, que era el formato de los documentos que mostraba el programa de navegación.

Tim Berners-Lee

Las ideas de Berners se materializaron en dos programas, por un lado el mencionado navegador Nexus, y por otro el CERN httpd, el servidor de páginas web. Ninguno de estos programas tuvo una vida muy larga; Nexus solo funcionaba en Next, así que no tardó en ser reemplazado por Mosaic, un navegador web creado por Marc Andreessen que funcionaba tanto bajo sistemas Unix como Windows. Respecto a CERN Httpd, no tardaría en ser reemplazado por Apache, un proyecto que nació como un fork del propio CERN Httpd para acabar convirtiéndose en el servidor web mas popular.

Actualmente, Tim Berners Lee es presidente del World Wide Web Consortium, un organismo creado para dirigir el desarrollo de las tecnologías relacionadas con la web.

El siguiente artículo continene un total de 37 puntos con respuestas frecuentes sobre HTML. En inglés. Estos son algunos de los puntos que trata el artículo:

16. Why do I need to write&instead of just&?
20. Why are external CSS and JavaScript files a good idea?
22. What does “semantic” mean?
23. Should I replacebandiwithstrongandem?
26. Are tables deprecated?
28. What is the correct use of thedfnelement type?
33. Must I have analtattribute for every image?

“HTML es la base de la Web y tanto desarrolladores como diseñadores necesitan comprenderlo”

37 Steps to Perfect Markup