El validador XML integrado

A partir de que el World Wide Web Consortium lanza la Web Accessibility Initiative, los problemáticas de validación XML y de accesibilidad de la Web para personas no videntes 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 escacez de páginas que lo cumplían: la mayoría de páginas HTML no XHTML hizo que los navegadores tuvieran su propio analizador, a la vez que los lenguajes basados en XML, como SVG o MathML, tuvieron un desarrollo muy lento en sus principio.

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 strict dice: mientras que la especificación oficial prohíbe el ajuste de los tags 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 proponiendo un validador extensible, integrado, incremental y opcional, basado en el Simple Analyzer for XML proporcionado como stándar por PHP. Esta amplitud de características lo hace útil tanto para webmasters y webmistress como a 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 un único tag abiertos y a lo sumo un atributo, con espacios blancos al margen izquierdo proporcionalmente al número de tags abiertos no cerrado. En el caso en que la página resulte inválida, este trabajo se ignorá, y el texto inicial será envíado al cliente HTTP. En estos casos, la puesta en cache posible tiene lugar después de la validación, que se cumple aquí de una simple compaginación.

Algunas observaciones que conciernen al tratamiento de los atributos. Su valor será sistemáticamente delimitado por apóstrofes, salvo si este contiene un apóstrofe en cuyo caso se rodeará de comillas (y si también tiene comillas será escrito "). 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 & < > y " que son corréctamente tratados por SAX (ya que es indispensable).

La lista de entidades y su valor serán deducidos del DOCTYPE indicado por el esqueleto; por defecto SPIP tomará por defecto un juego de caracteres equivalente al de la DTD de latin1 enriquecido por €, œ y Œ definido en la DTD de símbolos especiales.

Validación para los diseñadores gráficos

Para los creadores de esqueletos, la validación está disponibles a través del depurador introducido en SPIP 1.8. Esta herramientas 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 asuencia de DOCTYPE, indica:

• los mal formaciones de tags abiertos y cerrados;
• los atributos sin valor;
• los atributos sin delimitador;
• los atributos sin espacio delante;
• las entidades XML mal escritas (en particular & literal, ya que XML obliga a escribir &amp;).

Al primer error encontrado, el depurador de SPIP intentará inmediátamente encontrar el esqueleto del que proviene el error (en caso de que hayan varios incluidos) y en qué línea, dando vínculos hacia los archivos fuente (esta determinación puede no ser siempre bien aislado, un márgen de error debe ser tenido en cuenta).

Si este primer análisis es correcto, 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 será guardado en cache para acelerar los análisis ulteriores. Cada DTD puede incluir otro, que serán cargados a su vez. Con el fin de evitar las redundancias de cálculo teninedo 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. En ayuda de esta estructura, SPIP valida la página, es decir comprueba que:

• todos los nombres de atributos utilizados en un tag sean aceptados por el DTD;
• todos los atributos obligatorios de un tag 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, guíon bajo, guíon y dos puntos;
• todos los atributos de tipo IDREF o IDREFS referencian a ID presentes efectívamente dentro de la página;
• todas las entidades XML usadas están definidas en el DTD;
• todos los nombres de tags usados están definidos en el DTD;
• todo tag no vacío esté autorizado a estarlo por el DTD (por ejemplo un img no vacío será denunciado);
• todo tag vacío esté autorizado a estarlo por el DTD (por ejemplo un tr será denunciado);
• todo tag contenido dentro de un tag sea admitido como tal en el DTD;
• todo tag que deba aparecer antes que uno de sus hermanos, aparezca efectivamente así (por ejemplo head delante de body
• todo tag 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, con su número de ocurrencias, los links a las líneas afectadas y algunas sugerencias para su corrección deducida automáticamente a partir de 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 particularmente necesitan de 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, estándar o provenientes de una extensión, del espacio de readcción de SPIP 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 mouse, el análisis XML del resultado de un script Ajax activado en el espacio de redacción. Tal script no retorna una página HTML completa, sino sólamente un fragmento, el validador integrado fabricará una página con el DOCTYPE correspondiente, una cabecera reducida al tag Title y un tag Body compuesto de este fragmento. Una ventana se abrirá 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 durante el cuál apretar al menos una de las dos teclas Alt o Meta es obligatorio.

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 limites por el lugar del sitio. Este validador se aplica a cualquier documento XML; en ausencia de DOCTYPE, se usará el DTD XHTML1.0 transitional.

Como sugieren las líneas previas, el validador se aplica sin importar el DOCTYPE, incluso aquellos referenciandos 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 tags, se puede entonces construir fácilemente 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.