El validador XML integrado

A partir de que el World Wide Web Consortium lanza la Web Accessibility Initiative, los problemas de la validación XML y de la accesibilidad de la Web para personas con deficiencia visual convergieron.

Desde muy temprano, SPIP estuvo interesado en las cuestiones de accesibilidad, ya a partir de la versión 1.5 en 2002. Por otra parte, por mucho tiempo se abstuvo de XML dada la escasez de páginas que lo cumplían: la mayoría de páginas HTML que no eran XHTML hizo que los navegadores tuvieran su propio analizador, a la vez que los lenguajes basados en XML, como SVG, MathML y XQuery, tuvieron un desarrollo muy lento en sus principios.

No obstante, la convergencia de las problemáticas de accesibilidad y de validación por un lado, y la implementación nativa de SVG dentro los varios navegadores por el otro, llevó a SPIP, desde la versión 1.8.1, a ofrecer una interfaz con herramientas de validación como Tidy o el validador oficial del W3C. Estas herramientas, como lo indican sin rodeos las portadas de sus sitios, sufren de varias limitaciones, revelan divergencias en sus mensajes de error y no son instalables por el internauta promedio [1].

Además, son inútiles ante las nuevas tecnologías como Ajax, que modifican dinámicamente el contenido de una página Web. Mas grave aún, los Document Type Definition del W3C tienen también limitaciones, incluido el DTD XHTML 1.0 llamado strict: mientras que la especificación oficial prohíbe el ajuste de las etiquetas a, label o form, la definición formal de la gramática descrita considera como válidas las construcciones <label for='x'><label ... o <form action='.'><div><form... por ejemplo [2].

Ante esta situación, SPIP 1.9.2 innovó radicalmente ofreciendo un validador extensible, integrado, incremental y opcional, basado en el Simple Analyzer for XML proporcionado como estándar por PHP. Esta amplitud de características lo hace útil tanto para webmasters y webmistress como para los diseñadores gráficos y a los desarrolladores de extensiones de SPIP con obvias diferencias en su utilización.

Validación para webmasters y webmistress

Para ellos, incluir simplemente dentro del archivo mes_options.php la instrucción $xhtml = 'sax'; modificará la salida del código HTML producido por un esqueleto, cada línea compuesta por una única etiqueta de apertura y a lo sumo un atributo, con espacios blancos al margen izquierdo proporcionales al número de etiquetas abiertas sin cerrar. En caso en que la página resulte inválida, este trabajo se ignorará, y el texto inicial se enviará al cliente HTTP. En estos casos, la eventual puesta en cache tiene lugar después de que actúe el validador, lo que aquí se reduce a una simple compaginación.

Algunas observaciones que conciernen al tratamiento de los atributos. Su valor será sistemáticamente delimitado por apóstrofos, salvo si este contiene un apóstrofo en cuyo caso se rodeará de comillas (y si también tiene comillas será escrito &quot;). Debido a un error de concepción de SAX [3], las entidades XML serán préviamente convertidas al charset del sitio con excepción de &amp; &lt; &gt; y &quot; que son correctamente tratados por SAX (ya que es indispensable).

La lista de entidades y su valor serán deducidos del DOCTYPE indicado por el esqueleto; SPIP tomará por omisión un juego de caracteres predefinido equivalente al de la DTD de latin1 enriquecido por &euro;, &oelig; y &OElig; definidos en la DTD de símbolos especiales.

Validación para los diseñadores gráficos

Para los creadores de esqueletos, la validación está disponible a través del depurador introducido en SPIP 1.8. Esta herramienta solo es visible para los administradores del sitio, ya que disponen de los botones de administración cuando visitan las páginas del espacio público. Uno de estos botones se llama Analizar XML y lanza explícitamente la solicitud de validación de la página visitada. Este análisis es realizado por SAX que, aún ante la ausencia de DOCTYPE, indica:

  • las malas formaciones de etiquetas de apertura y cierre;
  • los atributos sin valor;
  • los atributos sin delimitador;
  • los atributos sin espacio ante el siguiente;
  • las entidades XML mal escritas (en particular un & literal, ya que XML obliga a escribir &amp;).

Al primer error encontrado, el depurador de SPIP intentará inmediatamente encontrar el esqueleto del que proviene el error (en caso de que haya varios incluidos) y en qué línea, dando vínculos hacia los archivos fuente (esta determinación puede no ser siempre acertada, hay que contar con un margen de error).

Si este primer análisis es correcto, esta nueva versión de SPIP va más allá teniendo en cuenta el DOCTYPE de la página. Esta puede ser de tipo PUBLIC o SYSTEM, y en el primer caso la DTD se guardará en la cache para acelerar los análisis ulteriores. Cada DTD puede incluir otros, que serán cargados a su vez. Con el fin de evitar las redundancias de cálculo teniendo en cuenta el sistema de inclusión condicional de los DTD, SPIP guarda también en el cache una estructura de datos específica que determina a partir de la lectura de todos las definiciones de elementos, atributos y entidades resultantes del DOCTYPE indicado. Con la ayuda de esta estructura, SPIP valida la página, es decir comprueba que:

  • todos los nombres de atributos utilizados en una etiqueta sean aceptados por el DTD;
  • todos los atributos obligatorios de una etiqueta estén presentes;
  • todos los valores de atributos satisfacen al tipo indicado oportunamente por el DTD;
  • todos los atributos de tipo ID tienen un valor compuesto de letras, números, guión bajo, guión y dos puntos;
  • todos los atributos de tipo IDREF o IDREFS hacen referencia a las ID realmente presentes en de la página;
  • todas las entidades XML usadas están definidas en el DTD;
  • todos los nombres de etiqueta usados están definidos en el DTD;
  • toda etiqueta no vacía está autorizada a estarlo por el DTD (por ejemplo una img no vacía será denunciada);
  • toda etiqueta vacía está autorizada a estarlo por el DTD (por ejemplo un tr vacío será denunciado);
  • toda etiqueta utilizada es hija de otra etiqueta que la admita como tal en el DTD;
  • toda etiqueta que deba aparecer antes que una de sus hermanas, aparezca efectivamente así (por ejemplo head antes que body
  • toda etiqueta que deba aparecer un número fijo de veces, aparezca efectivamente así (por ejemplo title una única vez dentro de head).

Si alguno de estos errores es detectado, el validador mostrará una tabla con todos los errores, su número de ocurrencias, los enlaces a las líneas afectadas y algunas sugerencias para su corrección deducidas automáticamente desde las construcciones permitidas por la DTD. En ausencia de errores, el depurador mostrará el código según la compaginación descrita anteriormente.

Validación para los desarrolladores

Las páginas Web de acceso restringido necesitan especialmente un validador integrado para su puesta a punto, ya que las herramientas de validación externa no tienen acceso explícito a estas páginas. En lo concerniente a los scripts del espacio de redacción de SPIP, estándar o provenientes de una extensión, se les aplica el validador de XML colocando $GLOBALS['transformer_xml'] = 'valider_xml'; en el archivo mes_options.php. El espacio privado de SPIP 1.9.2 cumple con XHTML 1.0 gracias a este mecanismo. Asignar a esta variable global el valor 'identer_xml' provocará la identación del código HTML si este es conforme XML, sin pasar por la validación.

También es posible realizar, con el ratón, el análisis XML del resultado de un script Ajax activado en el espacio de redacción. Como tal script no devuelve una página HTML completa, sino solamente un fragmento, el validador integrado fabricará una página con el DOCTYPE correspondiente, una cabecera reducida a la etiqueta Title y una etiqueta Body compuesta por ese fragmento. Se abrirá una ventana con el resultado del análisis, como para una página normal, mientras que la ventana inicial recibirá el resultado del script Ajax como de costumbre. Debido a una especificación del W3C inutilizable en cuanto al modelo de eventos [4], esta validación no es provocada por un botón específico, sino por hacer un click mientras se pulsa al menos una de las dos teclas Alt o Meta.

Además, el validador de SPIP puede ser aplicado en cualquier página publicada en la Web. Todo sitio SPIP instalado en la URL http://u contiene la página http://u/ecrire/valider_xml que los autores de sitios pueden invocar explícitamente para validar páginas sin limitarse a las propias del sitio. Pero este validador sólo se aplica a documentos XML; en ausencia de DOCTYPE, se usará el DTD XHTML1.0 transitional.

Como sugieren las líneas previas, el validador se aplica a cualquier DOCTYPE, incluyendo los que hacen referencia a DTD disponibles en el sitio. Para hacer accesible las páginas Web, se debe ser más riguroso en la utilización de atributos y etiquetas, se puede entonces construir fácilmente una herramienta de validación de accesibilidad escribiendo DTDs menos laxas que la XHTML 1.0 llamada estricta. Remplazar #IMPLIED por #REQUIRED en los atributos juzgados indispensables es instantáneo. Obligar input, select, textarea y button a ser exclusivamente hijas del tag label ya es un poco más difícil. Además, el validador acepta cualquier secuencia (en el sentido de PCRE) como tipo de atributo, se aplicará entonces a cada ocurrencia de este atributo dentro de la página analizada.

Finalmente, es posible definir tus propias reglas de validación asociadas a un atributo. Los tipos comunes ID, IDREF e IDREFS son implementados por las funciones validerAttribut_ID, validerAttribut_IDREF y validerAttribut_IDREFS. Basta con agregar un nuevo tipo S1 ... Sn dentro de la DTD, y definir las funciones asociadas en el archivo mes_options para habilitar los controles personalizados. Para el análisis, la función sobrecargable inc_valider_passe2 es llamada, para efectuar los controles retrospectivos (es aquí donde los atributos IDREF son verificables como referencias a atributos efectívamente presentes). Esta interfaz de programación todavía es un poco frustrante y será revisada después de experimentación. Sin embargo permite crear ya nuevas especificaciones de accesibilidad rápidamente.

Notas

[1El validador del W3C se presenta bajo la forma de un archivo de más de 1MB, compuesto esencialmente de un script CGI en Perl, dependiente de varios módulos de este lenguaje y de su interfaz con el servidor HTTP. Además, el análisis sintáctico y la validación no son efectuados por este programa, sino es delegado al analizador onsgmls, programado en C++ que necesita compilarse después de descargar los fuentes del proyecto OpenSP también de 1MB (aunque algunas distribuciones ya incluyen el archivo ejecutable de 128KB). Esta dificultad explica sin duda la escasez de implementaciones, que de vez en cuando son saturadas por los pedidos.

[2Esta falla intenta ser justificada en este pasaje de la recomendación XHTML que afirma: The HTML 4 Strict DTD forbids the nesting of an ’a’ element within another ’a’ element to any descendant depth. It is not possible to spell out such prohibitions in XML. Esta afirmación no está fundamentada por ninguna demostración o referencia científica. Los teoremas que demuestran la posibilidad del análisis sintáctico automático han sido enunciados y demostrados durante los años 1950, y contradicen tal afirmación. ¿W3C, ponte a estudiar?

[3Al encontrar de lo que se considera como un lexema (palabra raíz), SAX llama un suscriptor de eventos. A falta de considerar los atributos como lexemas, provocará la misma secuencia de llamada para los 3 textos siguientes:

&eolig;&EOlig;<a ...


&eolig;<a title='&EOlig;' ...


<a title='&eolig;' href='&EOlig;' ....


En consecuencia, el suscriptor de eventos Entidad XML no sabrá si la entidad que provocó su llamada forma parte del elemento que precede a la próxima etiqueta, o si forma parte de alguno de los atributos de esta etiqueta, y cuál. La ambigüedad no puede siquiera aclararse con la ayuda de los números de línea y de columna (o el carácter de flujo), que indican en todos los casos el lugar que precede a la etiqueta

[4Mientras que el sistema operativo más extendido del mundo seguía por una vez las sabias lecciones de Unix y más precisamente de X-Window, describiendo un botón del mouse mediante una máscara de bits, el W3C creyó apropiado inventar una especificación incompatible y mal concebida, que no sigue prácticamente ningún navegador

Autor o autora Miguel Publicado el: Actualizado: 26/10/12

Traducciones: عربي, català, English, Español, français, italiano