Il validatore XML integrato

Da quando il World Wide Web Consortium ha lanciato la Web Accessibility Initiative, le problematiche di validazione XML e di accessibilità del Web per gli ipovedenti si sono incontrate. SPIP si è interessato molto presto ai problemi di accessibilità, con la versinoe 1.5 nel 2002. Di contro, da molto tempo l’XML non ha seguito tale direzione, riguardo alla rarità delle pagine conformi: l’abbondanza delle pagine in HTML non XHTML fa in modo che i browser hanno il proprio analizzatore, e i linguaggi basati sull’XML, come SVG e XQuery, hanno sperimentato un avvio molto lento. Tuttavia, la convergenza delle problematiche di accessibilità e di validazione da un lato, e dell’implementazione in linguaggio nativo di SVG in diversi browser dall’altro lato, ha condotto SPIP, nella sua versione 1.8.1, a offrire una interfaccia con degli strumenti di validazione come Tidy o il validatore ufficiale del W3C. Questi strumenti, come indicano francamente le home page del proprio sito, soffrono di alcuni limiti, rivelano delle divergenze nei loro messaggi di errore, e non sono installabili dall’utente medio [1] Inoltre essi sono inoperanti riguardo alle nuove tecnologie come Ajax, che modificano in maniera incrementale il contenuto di una pagina Web. Ancor più grave, i Document Type Definition del W3C hanno anch’essi dei limiti, compresi il DTD XHTML 1.0 cosiddetto strict: mentre le specificazioni ufficiali vietano la nidificazione dei tag a, label o form, la definizione formale della grammatica descritta considera valide le costruzioni <label for='x'><label... o <form action='.'><div><form... per esempio [2].

Di fronte a questa situazione, SPIP 1.9.2 innova radicalmente proponendo un validatore estensibile, integrato, incrementale e opzionale, basato sul Simple Analyzer for XML fornito nel pacchetto standard di PHP. Questa pluralità di aspetti lo rende indicato sia per i webmaster che per i grafici e gli sviluppatori di plugin di SPIP ovviamente con delle manipolazioni diverse.

Validazione per i webmaster

Per i webmaster, mettere semplicemente nel file mes_options.php l’istruzione $xhtml = 'sax'; causerà una nuova impaginazione del HTML prodotto da un modello di layout, ogni riga avrà un solo tag di apertura e un attributo eventuale, con rafforzamento del margine sinistro proporzionale al numero di tag aperte e non chiuse. Nel caso in cui la pagina non venga validata, questo lavoro sarà ignorato, e il testo iniziale sarà inviato al client HTTP. Nei due casi, la messa in cache eventuale ha luogo ovviamente dopo l’azione del validatore, che qui si accontenta di una formattazione semplice.

Alcune precisazioni per quel che riguarda il trattamento degli attributi. Il loro valore sarà sistematicamente circondato da un apostrofo, salvo che se contiene un apostrofo, nel qual caso esso sarà circondato da virgolette (e se contiene anche virgolette, queste saranno scritte come "). A causa di un errore di concezione di SAX [3], le entità XML saranno precedentemente convertite nel charset del sito ad eccezione di & < > e " che vengono trattati correttamente da SAX (poiché ciò è indispensabile). L’elenco delle entità e del loro valore saranno dedotte dal DOCTYPE indicato dal modello di layout; in mancanza di esso SPIP prenderà un insieme predefinito equivalente alla DTD del latin1 arricchito da €, œ e Œ definiti nella DTD dei simboli speciali.

Validazione per i grafici

Per i creatori di modelli il validatore è disponibile attraverso il debugger introdotto nella versione SPIP 1.8. Questo strumento è visibile solo agli amministratori del sito, poiché dispongono di pulsanti di amministrazione quando visitano le pagine del sito pubblico. Uno di questi pulsanti si chiama Analisi XML e causa esplicitamente la richiesta di validazione della pagina visitata. Questa analisi è innanzitutto data a SAX che, anche in mancanza di DOCTYPE, analizza:

• le erronee nidificazioni di tag di apertura e chiusura;
• gli attributi privi di valore;
• gli attributi senza delimitatore;
• gli attributi senza spazio prima seguente;
• le entità XML scritte erroneamente (in particolare un & letterale, mentre l’XML impone di scrivere &amp;).

Al primo errore trovato il debugger di SPIP tenterà immediatamente di ritrovare da quale modello proviene l’errore (ve ne sono diversi in caso di inclusioni) e in quale riga, dando dei link verso i file sorgenti (questa individuazione non ha sempre successo, bisogna tenere conto di un margine di errore).

Se questa prima analisi è corretta, questa nuova versione di SPIP va ben oltre prendendo in considerazione il DOCTYPE della pagina. Esso può essere di tipo PUBLIC o SYSTEM, e nel primo caso il DTD sarà messo in cache per accelerare le analisi ulteriori. Ogni DTD può comprenderne altri, che saranno caricati in maniera simile. Al fine di evitare le ridondanze di calcolo pur tenendo in considerazione il sistema di inclusione condizionale dei DTD, SPIP mette ugualmente in cache una struttura di dati che deduce dalla lettura di tutte le definizioni di elementi, di attributi e di entità provenienti dal DOCTYPE indicato. Appoggiandosi a questa struttura, SPIP valida la pagina, in altre parole verifica che:

• tutti i nomi di attributi utilizzati in un tag sono accettati dal DTD;
• tutti gli attributi obbligatori di un tag sono presenti;
• tutti i valori di attributi sono conformi al motivo indicato eventualmente nel DTD;
• tutti gli attributi di tipo ID hanno un valore composto di lettere, cifre, sottolineati, trattini e due punti;
• tutti gli attributi di tipo IDREF o IDREFS fanno riferimento degli ID effettivamente presenti nella pagina;
• tutte le entità XML utilizzate sono definite nella DTD;
• tutti i nomi di tag utilizzati sono definiti nel DTD;
• qualsiasi tag non vuoto è autorizzato ad esserlo dal DTD (per esempio, un img vuoto sarà denunciato) ;
• qualsiasi tag vuoto è autorizzato ad esserlo dal DTD (per esempio, un tr vuoto sarà denunciato) ;
• qualsiasi tag utilizzato è figlio di un tag che l’ammette come tale nel DTD;
• qualsisi tag che deve apparire prima di uno di questi tag fratelli appare effettivamente così (per esempio, head prima di body)
• qualsiasi tag che deve apparire un numero fisso di volte appare effettivamente così (per esempio, title una sola volta dentro head).

Se si individuano degli errori il validatore mostrerà una tabella di tutti gli errori, con il numero di occorrenze, i link verso le righe incriminate, e dei suggerimenti di correzione dedotte automaticamente dalle costruzioni autorizzate dal DTD. In mancanza di errori il debugger mostrerà il codice secondo l’impaginazione descritta in precedenza.

Validazione per gli sviluppatori

Le pagine Web con accesso limitato hanno particolare bisogno di un validatore integrato per essere rifinite, poiché gli strumenti esterni di validazione non hanno accesso a tali pagine. Per ciò che riguarda gli script, siano essi standard o provenienti da plugin, dello spazio di redazione di SPIP gli si applica il validatore XML mettendo $GLOBALS['transformer_xml'] = 'valider_xml'; nel file mes_options.php. L’area riservata di SPIP 1.9.2 è stata resa conforme all’XHTML 1.0 grazie a questo meccanismo. Cambiare questa variabile globale con 'indenter_xml' causerà l’identazione del sorgente HTML se questo è conforme XML, senza cercare di validarlo.

E’ anche possibile lanciare, con il mouse, l’analisi XML del risultato di un o script Ajax attivato nell’area di redazione. Un tale script non restituice una pagina HTML completa ma solo un frammento di essa, il validatore integrato costruirà una pagina con il DOCTYPE attuale, un header limitato al tag Title, e un tag Body composto da tale frammento. Si aprirà una finestra con il risultato dell’analisi, come per una pagina normale, mentre la finestra iniziale riceverà il risultato dello script Ajax come al solito. A causa di una specifica W3C inutilizzabile per i modelli di eventi [4], questo lancio del validatore non è provocato da un pulsante specifico del mouse, ma da un clic durante il quale almeno uno dei due tasti Alt o Meta viene premuto.

D’altronde, il validatore di SPIP può essere applicato a qualsiasi pagina presente sul Web. Qualsiasi sito SPIP installato all’URL http://u contiene la pagina http://uecrire/valider_xml che gli autori del sito possono invocare esplicitamente per validare pagine non limitate a quella del sito. Questo validatore si applica tuttavia ai documenti XML; in mancanza del DOCTYPE, verrà preso il DTD XHTML1.0 Transitional.

Come suggeriscono le righe soprastanti, il validatore si applica a qualsiasi DOCTYPE, compresi quelli che si riferiscono a DTD residenti sul sito. Rendere accessibile delle pagine Web vuol dire essere più rigorosi nell’utilizzo degli attributi e dei tag, quindi si può facilmente construirsi uno strumento di validazione di accessibilità scrivendo dei DTD meno tolleranti dell’XHTML 1.0 cosiddetto strict. Sostituire #IMPLIED con #REQUIRED negli attributi giudicati indispensabili è immediato. Obbligare input, select, textarea e button a essere esclusivamente figli del tag label è poco più difficile. Inoltre, il validatore accetta qualsiasi motivo (nel senso di PCRE) come tipo di attributo, quindi esso sarà applicato ad ogni occorrenza di questo attributo nella pagina analizzata.

Infine, è possibile definire le proprie regole di validazione associate a un attributo. I tipi soliti ID, IDREF e IDREFS sono implementati dalle funzioni validerAttribut_ID, validerAttribut_IDREF, validerAttribut_IDREFS. E’ sufficiente introdurre un nuovo tipo S1 ... Sn nel DTD, e definire le funzioni associate al file mes_options per causare i controlli personalizzati. Alla fine dell’analisi, la funzione in ovverride inc_valider_passe2 viene chiamata, al fine di effettuare i controlli retrospettici (è qui che gli attributi IDREF vengono verificati come referenti di attributi effettivamente presenti). Questa interfaccia di programmazione è ancora un po’ manchevole e verrà rivista dopo la sperimentazione. Ma essa permette fin da ora di attuare delle nuove specificazioni di accessibilità.