NOTA: La presente página va dirigida a quien quiera hacer una página similar, y su contenido no es de interés jurídico, sino informático. Para entenderla hay que tener nociones de XML, LaTeX y, sobre todo HTML. Si no es así, aconsejo al visitante que se la salte.
La presente página se basa en el diseño de la página de mi buen amigo José Manuel Mira. De él he copiado (con su autorización) el diseño principal y la hoja de estilo. He cambiado, por supuesto, el contenido y la tecnología. El porqué de esto último es lo que intentaré explicar a continuación.
Todas las páginas de este sitio comparten el encabezado y el pie (idea tomada de José Manuel). Además van encadenadas una a la otra de forma que es posible leer la web entera "secuencialmente" como si fuera un libro (idea propia). Eso significa que muchas secciones de las distintas "páginas" serán idénticas o, al menos similares. Lo ideal sería tener que escribir esas secciones sólo una vez e insertar el texto común en cada una de las páginas.
Desgraciadamente HTML, el lenguaje de las páginas web, no ofrece esa funcionalidad. PHP sí lo hace, y esa fue la solución al problema que usó José Manuel Mira. Yo he preferido utilizar XML, en primer lugar porque me es más sencillo (nunca he manejado PHP y sí he trabajado algo con XML), pero, sobre todo, porque XML se presta a conseguir otra finalidad también importante para mí: En esta página pretendo incorporar textos legales los cuales pueden ser muy extensos y de cara a su impresión el formateo de una página web no es lo más adecuado. Para generar un texto legal impreso (o, lo que es lo mismo, en formato PDF) prefiero usar LaTeX, pues no conozco ningún sistema que ofrezca más calidad en textos impresos. Pero el marcado de LaTeX no se parece en nada al marcado de HTML, lo que en principio me obligaría a escribir dos veces los documentos, si quiero formatearlos de dos maneras; a no ser que encuentre una solución que me permita tener un fichero con, por ejemplo, el Código civil, y conseguir de forma automática formatearlo de dos formas una para su versión impresa y otra para mostrarlo en la Web.
Mi primera idea fue construir la página directamente en LaTeX, pues existen varias aplicaciones que permiten convertir un documento LaTeX a HTML. La más conocida es latex2html, pero hay otras varias. Si bien todas tienen el inconveniente de que hay que llevar mucho cuidado con el código en LaTeX para conseguir una total compatibilidad.
Por ello opté por construir todas las páginas en XML. Pues los documentos XML pueden vincularse a "hojas de transformación". Una hoja de transformación (también llamada hoja XSL) es también un documento XML (aunque suele llevar la extensión XSL) que usando el lenguaje XSLT especifica cómo convertir un documento XML en otro. Esto me permite:
Y así, por ejemplo, si en nuestro navegador pulsamos la opción de ver el código fuente de la página (en Mozilla-Firefox esa opción se activa pulsando CTRL-U) veremos que el documento que se está mostrando no es HTML puro. No tiene elemento HEAD, ni en él se ve de dónde salen las barras de los menús... Todo ello se genera en la segunda línea de código, que es la llamada a la hoja de transformación que convierte este documento en HTML cuando es cargado por un navegador de Internet (que sea compatible con XML, claro está).
La mayoría de las personas que diseñan páginas web, utilizan diseñadores visuales tales como Dreamweaver, Microsoft FrontPage (que formaba parte de Microsoft Office hasta hace bien poco, aunque hoy ha sido jubilado), o, en el mundo GNU/Linux, NVU o Kompozer.
Supongo que, como casi todo, la cosa irá en gustos. Personalmente prefiero escribir "a mano" mis documentos de texto. No es tan difícil ni tan "friki" como pueda parecer. Y es mucho más gratificante. Así sé exactamente lo que hay en ellos, y para modificarlos no necesito nada más que un editor de textos. Ni siquiera es necesario que sea un "buen" editor de textos: Podría cambiar mi página web incluso desde el NotePad (ejemplo paradigmático de mal editor de textos).
Pero, sobre todo: esas herramientas, lo que por un lado simplifican, por otro dificultan, puesto que con ellas se pierde flexibilidad. ¿Habría podido yo, con un diseñador WYSIWYG escribir estas páginas en un formato en el que es posible formatear de manera distinta según el destino del texto sea la web o un documento impreso?
A continuación expondré algunos problemas concretos que se me han planteado, en las hojas de transformación (con las que se genera la página web propiamente dicha a partir del fichero XML) y cómo los he resuelto (cuando lo he conseguido). Si algún lector conoce alguna solución mejor, le agradeceré que me la haga saber.
La mayoría de los problemas que menciono se refieren a las páginas de este sitio web que almacenan textos legales, ya que en ellas el dialecto XML utilizado es bastante más exigente que en las páginas normales (como la presente).
Desde el principio Internet Explorer me ha supuesto muchos quebraderos de cabeza. Afortunadamente gracias a las sugerencias de un amigo, he podido resolver los problemas que se planteaban, lo que agradezco especialmente ya que hay que asumir que, siendo ese navegador el más utilizado, será con el que normalmente se visitará esta página.
Debo hacer constar, no obstante, que aunque he conseguido superar esos problemas, la raíz de los mismos se encontraba en el hecho de que IE no es totalmente compatible con las especificaciones CSS. El alineado de párrafos, por ejemplo: en mi hoja de estilo original lo aplicaba al elemento body y en IE no funcionaba... Yo no podía suponer que en IE dicha especificación sólo funciona en los elementos P.
Por otra parte, no me gusta mucho el tipo de letra que IE elige para representar la página, ni su tamaño por defecto... Pero en fin: sobre gustos no hay nada escrito.
Este problema es mucho más serio; y como buscando en google no he encontrado ninguna solución, he tenido que inventar una solución propia que resuelve aparentemente el problema pero que no me termina de gustar (por las razones que luego diré).
El problema de las listas es doble (aunque la solución ha sido la misma).
Tratándose de listas numeradas, HTML no tiene ningún procedimiento para generar una lista en la que los números sean "ordinales", es decir, 1º, 2º, 3º, 4º, ... ó 1ª, 2ª, 3ª, 4ª ... en lugar de 1, 2, 3, 4, ...
Las enumeraciones de los textos legales, sin embargo, suelen ser con números ordinales y a veces, incluso, el saber si la enumeración es con ordinales masculinos o con ordinales femeninos puede ser importante para interpretar la norma: si, por la ambigüedad del texto legal, no queda totalmente claro qué es lo que se está enumerando, el uso del ordinal masculino o del femenino puede ayudar a determinarlo.
Las representaciones en Internet de los textos legales, sin embargo, ante este problema, se limitan a insertar listas numéricas ordinarias, perdiendo el carácter del ordinal. Así lo hace, por ejemplo, noticias jurídicas (un repositorio de textos legales que yo utilizo bastante). Otras veces lo que se hace es renunciar al uso de listas; así lo suele hacer, por ejemplo, la editorial Aranzadi , aunque esto tiene el inconveniente de que al perderse el sangrado típico de las listas, si el último elemento de la lista va seguido de un párrafo, puede haber dudas sobre si ese párrafo es el 2º párrafo del último elemento, y forma por lo tanto parte de la lista, o si, por el contrario, está fuera de la lista, y no se refiere sólo al último elemento de la lista.
En los textos legales es tan importante la literalidad, que ninguna de las dos soluciones es enteramente buena. Lo ideal sería poder usar una lista con ordinales.
Tratándose de listas alfabéticas HTML siempre las genera atendiendo al alfabeto inglés, es decir: la "ch", la "ll" y la "ñ" no existen. En los textos legales que he incluido en mi selección no había ningún caso en el que una enumeración alfabética incluyera la letra "ch", había un caso en el que se incluía la letra "ll" y varios casos en los que se incluía la letra "ñ".
Es curioso, por otra parte, ---y cambiando por un instante de tema--- como la preeminencia del alfabeto inglés hace que, aunque hay leyes que enumeran con la "ñ" hay otras que no lo hacen.
Otro inconveniente de estas listas es que si por ejemplo alguna norma introdujera en el futuro algún elemento nuevo en la lista, tal vez lo que haga sea renombrar todos los elementos a partir del nuevo; pero también es posible, y se hace con frecuencia, que el nuevo elemento se llame "bis", por ejemplo: "c bis", y ese tipo de elementos no se puede representar en las listas HTML estándar.
En mi selección legal había sólo un ejemplo de enumeración que usara una letra bis, y era la "z bis", que se incluyó exclusivamente porque faltaban letras para completar la enumeración, lo que, por otra parte, se habría podido arreglar, en ese caso, usando la letra "ñ" ya que esa lista concreta es de las que no usa la letra "ñ"; o con cualquier otro tipo de enumeración, usando números romanos, por ejemplo.
¿Como he resuelto el problema? En ambos casos del mismo modo: las listas ordinales y las listas alfabéticas en las que hay que representar caracteres no anglosajones o no estrictamente alfabéticos (como, por ejemplo, "c bis") se generan internamente como tablas de dos columnas: En la columna izquierda se imprime el identificador del elemento de la lista, y en la derecha se representa el contenido del elemento.
Desde un punto de vista visual no se ve diferencia entre unas listas (las verdaderas HTML) y otras (las generadas como tablas), salvo, acaso, una mayor distancia vertical entre los elementos de la lista en las segundas.
Por otra parte, la solución adoptada no me termina de convencer, porque tiene limitaciones. Por ejemplo en las falsas listas, alterar el valor de un elemento tiene como consecuencia (la mayor parte de las veces) que a partir de dicho elemento haya que alterar el valor de todos los demás. Eso es porque como XSL no admite auténticas variables, a las que se pueda cambiar el contenido (o, al menos, hasta donde yo se, no las admite), el único procedimiento que se me ha ocurrido para calcular el número de un elemento, es calcular su posición dentro de la lista, la cual es la misma con independencia de que los elementos previos tengan algún valor específico o no. O dicho con otras palabras: el cuarto elemento de la lista es siempre el cuarto elemento de la lista, con independencia de que el tercer elemento de la lista, en lugar de ser "c" sea "b bis". De modo que mi rutina de generación automática de números, dirá siempre para el cuarto elemento de la lista, que le corresponde "d". Por eso, una vez que he fijado manualmente el valor del tercer elemento, me veo obligado a fijar manualmente el valor de todos los elementos a partir de él.
Otro inconveniente es que al preparar el documento XML para su correcta representación en HTML (fijando manualmente el valor de todos los atributos a partir de aquel en el cual se haya incidido), hago que la representación en LaTeX (donde no existen las restricciones de listas que hay en HTML) sea más compleja de lo debido.
Este problema se plantea también en las leyes. Como pretendo poderlas formatear para HTML y para LaTeX, en el texto de las mismas no puedo usar ningún carácter que esté reservado en ninguno de esos dos sistemas.
En particular: los signos "<" y ">" no se pueden representar en HTML, aunque en LaTeX son muy usados para las fórmulas matemáticas; mientras que el carácter "%" así como las comillas dobles, no se usan en LaTeX.
Para resolver este problema he creado elementos XML que sustituyen a esos caracteres; de modo que sea la hoja de transformación la que en cada caso decida que imprimir, y así, por ejemplo, el elemento <porciento /> se convierte, en documentos HTML en el carácter "%" y en documentos LaTeX en la pareja de caracteres "\%".
La mayoría de los sitios web dedicados a la legislación (con la salvedad de la base de datos de la editorial Aranzadi), dividen los textos legales muy extensos, de modo que se carguen por partes. Eso tiene el inconveniente de que dificulta la búsqueda textual dentro de la norma (hay que repetirla tantas veces como partes se hayan generado) y además, obliga a llenar el texto de hipersaltos, cada vez que una norma se cita a sí misma (porque no estaremos seguros de que ese artículo citado, esté en la página actual).
Para evitar estos inconvenientes desde el principio decidí que los textos legales se cargarían siempre enteros. Si bien soy consciente de que ello tiene el inconveniente de que en ciertos textos legales se aumenta considerablemente el tiempo de carga. Mucho más si se tiene en cuenta que antes de cargar la página hay que convertirla, y que durante el proceso de conversión hay que generar el índice (que se genera dinámicamente).
Supongo que si se tiene un ordenador lento, o se navega con una mala conexión a Internet, esa decisión puede parecer bastante discutible.