Ecologia dei siti web.net

1 dicembre 05

Dalla validità alla conformità, passando per il web semantico

di Maurizio Boscarol

Quando si parla di validità o di conformità di documenti XML spesso si confondono o sovrappongono termini che vogliono dire cose diverse. Proviamo a fare un po’ di luce per sgomberare il campo da equivoci.

Buona forma del codice

Un documento è ben formato quando è strutturato in maniera conforme alle regole espresse in questa sezione 2.1 delle specifiche XML. Ovvero:

  1. Quando è un documento nel senso indicato qui.
  2. Quando rispetta i vincoli di buona-forma indicati in questa specifica.
  3. Quando ogni sua entità parsabile è ben formata.

In spiccioli, un documento è ben formato quando tutti i suoi elementi sono annidati correttamente, secondo le regole dell’XML, ed esiste un’unica radice. E’ dunque una proprietà puramente sintattica.

Un documento può essere ben formato anche se usa tag e attributi che non sono noti. La buona forma è infatti indipendente dal “vocabolario usato”. Dunque potremmo usare nel nostro documento anche tag inventati da noi. Se sono annidati correttamente esso rimarrebbe ben formato. Però non sarebbe valido, nel senso che ora vediamo.

Validità

Un documento XML è valido se:

  1. ha un’associata dichiarazione di Document Type
  2. il documento è conforme ai vincoli in essa espressi.

La validità dunque è la conformità con la DTD. Solo ciò che viene indicato nella DTD è importante. Ovviamente, è necessario che sia pure ben formato (prerequisito di tutti i documenti XML, sia che abbiano una DTD che non ce l’abbiano): ma solo gli elementi e gli attributi indicati nella DTD indicata sono in questo caso utilizzabili.

La validità ha a che fare con la grammatica del documento, non solo con la sintassi. Nella DTD è indicata (nella descrizione di elementi e attributi) anche la semantica degli elementi e degli attributi ammessi. Nell’XHTML 1.0 la semantica è la stessa di HTML 4.01.

Documenti rigidamente conformi

Validità e conformità con le specifiche XHTML sono ancora due cose diverse. La conformità è il rispetto di ulteriori regole stabilite nella sezione 3.1 della specifica per l’XHTML.

Il documento deve:

  1. Essere conforme alla DTD (valido e ben formato) e ad un ulteriore set di proibizioni non presente nella DTD e definito nell’appendice B della specifica: in particolare gli elementi a, label e form non possono rispettivamente contenere altri elementi con il proprio nome; e pre e button non possono contenere degli altri elementi elencati nella specifica.
  2. L’elemento radice deve essere html.
  3. L’elemento radice deve contenere una dichiarazione di namespace di tipo xmlns con la seguente indicazione: “http://www.w3.org/1999/xhtml.”. Il risultato per una pagina in italiano è: <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="it" lang="it">.
  4. Ci dev’essere in cima al documento una dichiarazione di DOCTYPE relativa ad una delle tre DTD consentite (transitional, frameset o strict), prima dell’elemento radice.
  5. Eventuali altre definizioni di differenti sottoinsiemi di DTD interne al documento non devono sovrascrivere la DTD originaria.

Dunque la conformità di un documento XHTML alle specifiche è ben più della validità: comporta la conformità ad una serie di regole più stringenti, e solo il rispetto di queste regole attesta la conformità alle specifiche.

I validatori automatici

I validatori non sono dunque sufficienti per accertare in maniera automatica la conformità di un documento alle specifiche. Possono solo indicare la validità (cioè la buona forma del codice nel caso dell’XHTML e l’utilizzo di elementi e attributi consentiti nel caso di HTML e XHTML).

Non possono nemmeno chiarire se la semantica utilizzata è corretta o meno, e se il contenuto degli attributi e degli elementi è sensato e comprensibile.

Cos’è importante per l’accessibilità

Paradossalmente, per quanto attiene all’accessibilità, la semantica del documento è molto più importante delle altre regole formali. Ad esempio, alle volte è più importante che un elemento abbia una corretta semantica piuttosto che abbia una buona forma, almeno per i browser attuali.

Infatti, i browser attuali sono abituati ad affrontare, entro certi limiti (non in qualunque caso) una cattiva forma del documento, restituendo comunque all’utente una resa comprensibile, anche se non sempre univoca, del contenuto. Ma l’assenza di una corretta semantica, cioè un uso improprio dei marcatori in relazione al senso del contenuto ostacola irrimediabilmente alcune funzionalità delle tecnologie assistive.

Ad esempio alcuni lettori di schermo consentono di navigare nel documento saltando di titolo in titolo, evitando il contenuto. O attraverso le liste. Anche se spesso sono in grado di sopportare (cioè di non esibire comportamenti eccentrici) la mancata chiusura di qualche tag. Se i titoli o le liste non sono correttamente marcati queste funzionalità vengono meno. Mentre se non sono tutti chiusi il meccanismo può funzionare lo stesso.

Questa situazione non è presa in considerazione da nessuno dei concetti sopra visti, perché la buona forma è addirittura il primo dei requisiti del codice XML. Dunque non è previsto il superamento di nessuna verifica se, ad esempio, un tag non è correttamente chiuso. Anche se in realtà tutti i browser in uso attualmente sono in grado di affrontare molti di questi problemi senza creare particolari ostacoli agli utenti.

La realtà è più fantasiosa della teoria

La realtà è ben diversa dalla teoria per ragioni storiche. In HTML il concetto di buona forma non esiste (sebbene in SGML progenitore di entrambi i linguaggi, esista il concetto di “non-overlapping”, di non sovrapposizione degli elementi) e nelle specifiche non viene specificato cosa dovrebbero fare gli user agent quando incontrano codice che non annida in maniera appropriata gli elementi.

In questo modo, ogni browser ha escogitato propri modi per affrontare il codice HTML mal annidato. Se siete interessati al come, c’è un interessante articolo di Ian Hixie al riguardo su come si comportano Explorer, Mozilla e Opera con codice che oggi chiamiamo mal formato.

Dato che per anni il codice HTML è stato quanto di peggio formato si potesse avere, è chiaro che nessun browser che non fosse in grado di dare comunque un senso al contenuto non avrebbe avuto alcuna speranza di successo commerciale.

Il fatto che XML prescriva ora agli user agent di interrompere l’interpretazione di codice valido ci pone in una situazione paradossale: nessun browser ha davvero bisogno di questo rigore, e, anzi, se rispettasse questo vincolo creerebbe agli utenti molti più problemi di quanti non ne risolverebbe!

Ecco perché, sebbene in teoria è sensato e corretto dire che i documenti devono essere validi e ben formati, in realtà ed entro certi limiti non è sempre così importante quanto il fatto che abbiano una buona semantica – e ovviamente che abbiano contenuti di buona qualità. Tuttavia non c’è un modo per dirlo nelle specifiche del W3C, che per loro natura possono normare solo la correttezza sintattica e grammaticale del codice. E’ semplicemente un dato di fatto che ci limitiamo ad accertare, dovuto a ragioni storiche.

Motori di parsing

I browser più recenti incorporano 2 diversi motori di parsing. Uno per i contenuti che riconoscono come HTML, e uno più snello (perché non deve comprendere delle regole per correggere gli errori) per i documenti XML.

Ciò che non tutti sanno, però, è che qualsiasi documento XHTML servito con il mime-type text/html viene trattato come se fosse un documento HTML, e dunque viene passato al vecchio motore di parsing, che tutti continuano ad implementare per ragioni di retrocompatibilità.

L’unico modo per attivare il motore di parsing più snello e rigoroso è fornire i documenti XHTML con il tipo mime application/xhtml+xml (o altri mime type che per brevità non affrontiamo). In quel caso, se il documento non è ben formato il browser smette di interpretarlo, e non restituisce alcun risultato se non un messaggio di errore.

Vantaggi e svantaggi

Questo è desiderabile o no? Dipende da che lato guardiamo la cosa. Dal lato dell’utente questo è uno svantaggio, perché in assenza di adeguati controlli in fase di pubblicazione della pagina, si troverebbe a non fruire di alcun contenuto, neanche parziale, neanche errato o approssimato. Questo indipendentemente dalla gravità dell’errore di codice. Anche un semplice carattere non legale o un br non chiuso restituirebbe lo stesso risultato che si avrebbe con il peggior tag-soup: un messaggio di errore.

Dal lato di chi produce contenuti, questo è un onere in più: infatti bisogna effettuare dei controlli di validità su ogni materiale pubblicato, per evitare che si possano creare inconvenienti agli utenti.

Dunque, a chi giova realmente questo meccanismo? In realtà, al momento, non giova a nessuna delle due parti in causa: utente e autore di contenuti. Il vero vantaggio è di prospettiva. Infatti, la speranza degli estensori di queste regole è probabilmente di evitare in futuro che si producano pagine non conformi. Se il web fosse composto solo di pagine perfettamente ben formate, valide e conformi, allora i vantaggi sarebbero i seguenti:

  1. I browser potrebbero non implementare più il vecchio motore di parsing, perché non ci sarebbero più contenuti mal formati da correggere; tuttavia questa prospettiva appare alquanto improbabile per decenni, perché significherebbe non poter più visitare le pagine vecchie e ancora residenti sui server che nessuno mantiene più. E’ dunque improbabile che qualche browser rinunci a implementare anche il motore che “corregge” gli errori.
  2. Gli amministratori dei siti potrebbero sfruttare una serie di strumenti che funzionano solo con XML ben formato e che consentono di operare trasformazioni sui contenuti, attraverso fogli di stile XSL o altri meccanismi; il vantaggio è quello che offre ad esempio già oggi una piattaforma come Cocoon per Apache. Chi non usa questi strumenti, però, non trae particolari vantaggi dal rigore di XML.
  3. Chi volesse estendere correttamente XHTML con moduli aggiuntivi come MathML. Per poterlo fare c’è però bisogno del supporto dei browser o di alcuni plugin. Al momento non si tratta di possibilità adatte al pubblico di massa, ma potrebbero esserlo in futuro, se i browser futuri saranno capaci nativamente di supportare queste novità. Anche allora, però, i browser, accanto alle nuove funzionalità dovrebbero implementare un motore di parsing per HTML per poter accedere alle vecchie pagine.
  4. Il web semantico. Il web semantico spera infatti che un giorno sarà possibile compiere operazioni logiche sui dati presenti nelle pagine web (o su altri documenti, non necessariamente pagine web) se queste saranno riccamente marcate. Se questo sarà possibile e se porterà effettivamente a possibilità vantaggiose è oggetto tuttora di discussioni. Gli scettici obiettano la difficoltà o addirittura l’impossibilità di costruire ontologie complete, mentre, sul versante degli entusiasti dei social network si obietta che le ontologie potrebbero essere meglio rimpiazzate da classificazioni spontanee e “fuzzy” sul genere delle folksonomy.

Il vantaggio del rigore di XML si potrà forse apprezzare meglio su altri tipi di linguaggi, come RSS. Con questi linguaggi, che non hanno problemi di compatibilità all’indietro, i programmatori potranno decidere di realizzare motori di parsing più snelli fin da subito. Anche se il problema di implementare comunque meccanismi di correzione dell’errore si è già posto. Alcuni reader infatti leggono anche feed RSS non perfettamente validi.

Esperti di codice vs. Esperti di comunicazione?

In definitiva, quello della conformità e della validità, sembra un problema più teorico e di prospettiva, che di reale impatto ora come ora, ed entro – non ci stancheremo di dirlo – certi limiti. Anche se produrre codice conforme alle specifiche è pur sempre una garanzia per clienti e utenti, ed incoraggiamo a farlo, troppi sono ancora i fattori che ostacolano il mantenimento nel tempo di pagine conformi a costo zero. Se i CMS implementeranno meccanismi di correzione della cattiva forma, impedendo la pubblicazione delle pagine che non riescono a correggere, allora la pubblicazione di pagine ben formate sarà alla portata di tutti. Altro discorso per questioni come la buona semantica, che nessun programma può garantire.

In caso contrario, l’obbligo alla conformità ad ogni costo rischia di rallentare la pubblicazione di contenuti in presenza di strumenti ancora imperfetti. E come effetto collaterale ha quello di ipervalutare le competenze dei coders, di coloro cioè che fanno del solo codice valido il motivo del proprio “vantaggio competitivo”. Un vantaggio che nella realtà ha un impatto ancora basso sulla comunicazione online: tutto sembra funzionare in maniera abbastanza simile sia con codice conforme sia con codice non perfettamente conforme per una buona maggioranza di utenti – persino disabili – dati gli strumenti attuali, cosicché non si percepisce alcun vantaggio reale.

Siccome però è improbabile che semplici autori di contenuti senza competenze tecniche, che oggi pubblicano senza problemi contenuti comprensibili anche se non sempre conformi, riescano ad imparare in breve tempo i segreti di Pulcinella del codice valido (è un altro mestiere…), ecco che si rischia di creare un bisogno artificiale, quanto meno non compreso. In nome del codice valido i semplici autori di contenuti diventano non più sufficienti, e devono essere affiancati o sostituiti da esperti di codice, almeno in assenza di strumenti più evoluti. E’ davvero questa la competenza più importante quando si tratta di pubblicare online? O non conta di più forse la capacità di scrivere contenuti interessanti e corretti dal punto di vista della lingua italiana e appropriati alla strategia comunicativa? Non dovrebbero forse esistere degli strumenti che semplicemente consentano anche ad autori che non conoscono l’HTML di pubblicare codice comunque valido senza tanti problemi, se vogliamo diffondere una reale democrazia di rete?

Ai poster (dei prossimi convegni scientifici) l’ardua sentenza…

Sezione: blog - Argomenti: (x)html, web semantico |

Commenti:

  1. — Paolo Sordi    1 12 2005 - 12:49    # In effetti, la sbandierata validazione del codice e dunque la sua correttezza formale/ortografica ha davvero senso se propedeutica a un utilizzo semanticamente corretto del codice stesso. Ma per questo, come dici giustamente, abbiamo bisogno di saper scrivere in italiano e conoscere come si struttura un documento. Ho paura che invece, dietro lo schermo tecnico della validazione, si nasconda una drammatica impreparazione culturale sia dei coders sia degli autori di contenuti.
  2. — Andrea Paiola    7 12 2005 - 15:24    # Errorino:

    Il risultato per una pagina in italiano è:
    xml:lang=”it” lang=”it”

    ciao,
    Andrea.
  3. — Maurizio    7 12 2005 - 15:44    # Sì, ovviamente sì. :)
    Grazie, corretto.
  4. — Andrea Paiola    10 12 2005 - 01:56    # Un’altra cosa: porti come esempio di impiego felice di XML la tecnologia feed…

    bè non è tutto rosa e fiori: faccio presente che esistono almeno 7 diverse (molto diverse) varianti di RSS, poi c’è atom (anche lì 2 o 3 versioni diverse…)

    insomma per adesso non ho visto un uso lato client di xml che non dia problemi… bisogna sempre rompersi la testa con rompicapi sulle versioni delle specifiche e (in)compatibilità varie.

    Il mio augurio è per un futuro + standard e per specifiche più condivise.

    ciao,
    Andrea.
  5. — Maurizio    10 12 2005 - 16:53    # Non ho detto che è un uso felice, ma che forse con gli RSS possiamo sfruttare meglio il rigore formale di XML, nel senso che almeno non abbiamo l’eredità di formati basati su regole diverse. Forse non era chiaro dal contesto.

    Il fatto che ci siano molti dialetti, poi, in qualche maniera però è incoraggiato da XML stesso, che è un metalinguaggio che incoraggia alla creazione di linguaggi. Questo è insomma un problema che suppongo si ripeterà in futuro, con altre specifiche, e che è addirittura connaturato a XML. Almeno però rispetteranno tutti le stesse regole di fondo e saranno più facilmente e univocamente parsabili, nonché comunque estensibili: credo che alla fine il vantaggio si riduca a questo, e non è poco. Ma per ora non è nemmeno molto… :)
  6. — Andrea Paiola    11 12 2005 - 10:05    # Cito:
    “Il vantaggio del rigore di XML si potrà forse apprezzare meglio su altri tipi di linguaggi, come RSS. Con questi linguaggi, che non hanno problemi di compatibilità all’indietro, i programmatori potranno decidere di realizzare motori di parsing più snelli fin da subito. Anche se il problema di implementare comunque meccanismi di correzione dell’errore si è già posto. Alcuni reader infatti leggono anche feed RSS non perfettamente validi.”

    Facevo solo presente che non è vero che RSS non ha problemi di compatibilità all’indietro… da come hai scritto sembra così... poi bisogna anche vedere cosa intendi per compatibilità all’indietro: usando XSL posso trasformare da un formato all’altro, ma faccio presente che dal punto di vista semantico sarebbe un’ecatombe.
    RSS sono troppo diversi tra loro per avere una reale compatibilità: col vero web semantico, le ontologie e le inferenze forse si può sperare in questa compatibilità.

    ciao,
    Andrea.
  7. — Maurizio    11 12 2005 - 10:25    # Sì, per compatibilità all’indietro si possono intendere entrambe le cose, hai ragione. Io mi riferivo al fatto che il problema di XHTML è che deve mantenere una certa compatibilità con HTML (da cui l’appendice C delle specifiche), limitando di fatto alcune funzionalità tipiche di XML come la modularizzazione.

    Inoltre, i problemi di compatibilità fra formati RSS si possono anche risolvere scegliendo i due formati più diffusi. Per di più è un problema per lo più dei feed reader, non tanto degli autori. Terzo: ma questo non era già prevedibile quando ci hanno detto che con XML chiunque può costruirsi il suo linguaggio? Io mi preparerei a vederlo accadere anche in futuro…

    Quarto, anch’io come altri ho delle perplessità sul web semantico immaginato dal W3C e sulla realizzabilità delle ontologie e gli algoritmi inferenziali. Può darsi che queste perplessità siano fuori luogo, ma a me pare qualcosa che l’intelligenza artificiale sta cercando senza successo da troppo tempo, per sperare che risolverà tutti i problemi. Insomma, se dal punto di vista teorico sono perplesso, aspetto di vedere le applicazioni pratiche, fra dieci – vent’anni… ;-)

    Tu hai ragione a dire che è invece un problema di standard. Ma del lato commerciale e politico dello standard, non di quello tecnico. Il problema è che gli standard sono emessi da istituti normatori che sono accettati dalle industrie di settore. Nel campo del web, a parte che il W3C non è un ente normatore (l’ISO lo è), pare che le specifiche non siano tanto accettate da chi dovrebbero farlo, cioè i produttori di browser, di cms, di sistemi operativi… ognuno implementa il sottoinsieme degli standard che gli pare. Questo non succede con i fogli di carta. Non è che l’A4 Fabriano è largo 211 millimetri. E’ sempre largo 210.

    Ma questo è un problema di status del W3C, temo. In parte è forse un problema di bontà di alcuni standard. E rimarrebbero comunque problemi legati alla compatibilità all’indietro. Insomma, il materiale di discussione non manca certo…
  8. — Andrea Paiola    11 12 2005 - 11:50    # Per risolvere il problema degli standard forse ci dovrebbe essere maggiore collaborazione tra ISO e W3C…
    il W3C sembra davvero per certi versi un meccanismo all’italiana che fa le norme ma non le fa rispettare… ;-) sarà per questo che lo trovo adorabile?
    daltronde il w3c è formato praticamente da quasi tutte quelle aziende che poi devono interessarsi delle norme ISO…
    dal punto di vista teorico la collaborazine (se non addirittura una dipendenza da parte dell’ISO verso il W3C) dovrebbe essere molto maggire di quanto appare ora.

    ciao ciao
  9. — Maurizio Boscarol    12 12 2005 - 12:07    # C’è un accordo fra W3C e ISO, per quel che ne so io, anche se non so bene di quale natura sia. Fatto sta però che è l’ISO a dover recepire gli standard del W3C prima che diventino in qualche maniera vincolanti.

    Le istituzioni (UE e governo italiano, ad esempio) recepiscono già le raccomandazioni. Il problema sono le aziende che producono browser, tecnologie assistive, CMS e sistemi operativi.

    Però, nel caso di XML, siamo sicuri che non sia nella natura stessa della specifica il rischio di avere numerosi linguaggi per lo stesso scopo?...

    Tempo fa c’era anche chi suggeriva di farsi la propria DTD per le pagine web per far validare l’elemento embed ...
  10. — Andrea Paiola    13 12 2005 - 16:15    # ti faccio subito un esempio della potenza (o selvaggezza) di XML
    http://www.cssplay.co.uk/menus/dropdownfun.html
    inserisci delle tabelle nei links (sì hai capito bene) per correggere errori delle varie versioni di IE

    che ne pensi?

I commenti sono chiusi per questo articolo.