Archivio > Markup, Standards > Singolo: XHTML 1.1 e Modularità

XHTML 1.1 e Modularità

Se ne parlava qualche tempo fa in una delle tante lezioni curate da Simone Onofri per OilProject, incentrate su Semantica e Web Standards.

In particolare, l’argomento è caduto sull’uso di XHTML 1.1, e sulle differenze più evidenti dalla precedente versione 1.0. Si è parlato di modularità, e il discorso infine si è spostato principalmente su una domanda di fondo: Perchè non usare XHTML 1.1?. Seguendo le orme delle risposte datemi da Simone, ho fatto qualche ricerca sull’argomento, e vi propongo quelli che sono stati i risultati di questo documentarmi.

[Immagine] Vediamo passo passo quali sono le caratteristiche salienti della versione modulare di XHTML, che caratterizza per prima la versione 1.1 e permette un'ampia condivisione di elementi e attributi appartenenti a grammatiche XML, favorendo il dialogo fra più linguaggi di marcamento.

Modularità? Cos’è?

Innanzi tutto è bene chiarire il concetto di modularità.

Partiamo subito con la definizione di moduli astratti:

An XHTML document type is defined as a set of abstract modules. A abstract module defines one kind of data that is semantically different from all others. Abstract modules can be combined into document types without a deep understanding of the underlying schemas that define the modules.

Un document type XHTML è definito come un’insieme di moduli astratti. Un modulo astratto definisce un tipo di dato che è semanticamente differente da tutti gli altri. I moduli astratti possono essere combinati nei document types senza una profonda comprensione degli schemi fondamentali alla base dei moduli.

Un esempio di doctype può essere quello di XHTML 1.1: guardiamolo insieme. Esso è costituito da moduli divisi per tematica: da quelli struttuali (che definiscono cioè elementi creati allo scopo di strutturare il documento vero e proprio) a quelli di formattazione dei testi, passando per alcuni insiemi “extra” (ad esempio l’estensione Ruby per gli scritti asiatici).

Sulla base di questa definizione, diamo ora quella di modularità:

XHTML Modularization is a decomposition of XHTML 1.0, and by reference HTML 4, into a collection of abstract modules that provide specific types of functionality. […] These modules may be combined with each other and with other modules to create XHTML subset and extension document types that qualify as members of the XHTML-family of document types.

La modularizzazione di tipo XHTML consiste in una decomposizione in moduli dell’XHTML 1.0, e sulla base di HTML 4, in una collezione di moduli astratti che forniscono determinati tipi di funzionalità. […] Questi moduli possono essere combinati fra di loro e con altri moduli per creare sottoinsiemi XHTML e estensioni dei document types appartenenti alla famiglia XHTML.

Questo ci permette quindi di combinare, estendere, modificare e personalizzare i moduli XHTML predefiniti, per ricavare dall’insieme di queste operazioni un linguaggio di marcamento che si adatti perfettamente alle nostre esigenze. E’ insomma un’arricchimento importante sotto l’aspetto della flessibilità che ci porta sempre più vicini alla sua natura XML.

Perchè modularizzare?

L’esigenza che col tempo si è sentita sempre più viva nelle menti di chi produceva documenti aderenti alle specifiche consisteva nella possibilità di portare l’HTML ad un gradino più alto, dove il suo campo d’azione potesse rivelarsi ben più vasto del previsto: ramo mobile (cellulari, dispositivi portatili) e multimediale (browser da televisione, proiettori), programmazione, persino negli uffici o nei magazzini (attrezzature varie). Con una sintassi così chiara ed immediata, ne risulta un utilizzo altrettanto intuitivo e facilitato, adatto a più occasioni, pronto a diventare economicamente vantaggioso in più settori e situazioni.

Tuttavia, prima che questo fosse fisicamente possibile, era necessario ridefinire la struttura di base del linguaggio, rivederne caratteristiche e priorità, trarre ed ereditare i benefici dai metalinguaggi ad esso superiori. Stiamo parlando di XHTML come risultato e XML come ispirazione. Ne otteniamo quindi una sintassi che è a metà strada tra semplice HTML e applicazioni più avanzate.

Si tratta quindi di (ri)definire uno standard con delle leggi più severe, ma allo stesso tempo estremamente permissive se ben interpretate:

The use of standards is critical for modularized XHTML to be successful on a large scale. It is not economically feasible for content developers to tailor content to each and every permutation of XHTML elements. By specifying a standard, either software processes can autonomously tailor content to a device, or the device can automatically load the software required to process a module.

Modularization also allows for the extension of XHTML’s layout and presentation capabilities, using the extensibility of XML, without breaking the XHTML standard. This development path provides a stable, useful, and implementable framework for content developers and publishers to manage the rapid pace of technological change on the Web.

L’uso degli standards è critico affinchè la modularizzazione abbia successo su vasta scala. Non è economicamente fattibile per gli sviluppatori adattare i loro contenuti in base ad ogni mutamento che subiscono gli elementi XHTML. Specificando uno standard, invece, il software può autonomamente adattare i contenuti ad un dispositivo, o esso stesso può automaticare caricare il software richiesto per processare un modulo.

La modularizzazione permette anche di estendere le possibilità di XHTML per quel che concerne struttura e presentazione, usando l’estensibilità di XML, ma senza rompere gli standard XHTML. Tutto ciò offre a sviluppatori ed editori un ambiente di sviluppo stabile, utile e implementabile per controllare la rapida andatura delle scelte tecnologiche sul Web.

Per spiegare con altri termini e in maniera più semplice quello che è stato scritto sino ad ora, la possibilità di ragionare sopra ad XHTML in maniera modulare ci offre un’ampia gamma di possibilità e modalità d’utilizzo del linguaggio. L’esempio proposto è quello di un dispositivo qualunque (ad esempio un cellulare) che integra nativamente un browser per navigare in internet. Utopisticamente l’applicazione analizzerà il codice XHTML della pagina, selezionando e combinando insieme solo determinati moduli (in base alle proprie capacità di rendering), e presentando infine all’utente finale la pagina richiesta nel migliore dei modi - forse anche nei tempi più brevi.

Si rompe quindi ogni tipo di dipendenza dall’intero doctype. La fruibilità del codice è garantita dalla scissione di elementi ed attributi in moduli differenziati tra di loro, che possono tuttavia influenzarsi a vicenda e estendere le loro possibilità dialogando.

Come?

Scrivere un modulo: implementazione

Ci sono due standards W3C attualmente destinati alla scrittura di moduli per la versione modulare di XHTML:

Personalmente, pur non avendo mai scritto nulla con lo standard DTD, mi sono trovato subito a mio agio con la sintassi XML Schema, proprio perchè essa condivide le stesse regole della genitrice XML: l’unico sforzo consiste nel studiare e comprendere la relazione tra elementi di tipo semplice, complesso, e così via, ma non è questo il luogo per discuterne.

Le regole

Come ogni cosa, anche la stesura o la modifica di un modulo ha le proprie regole. In particolare, gli standards prevedono 5 approcci diversi (conformità) alle operazioni sui document types:

  1. XHTML Host Language Document Type Conformance
  2. XHTML Integration Set Document Type Conformance
  3. XHTML Family Module Conformance
  4. XHTML Family Document Conformance
  5. XHTML Family User Agent Conformance

Ognuno di essi stabilisce cosa dev’essere un document type, quali moduli di base deve contenere, come specificare il doctype nel documento. Un esempio? L’XHTML Host Language Document Type Conformance esige che il document type contenga di default i moduli _Structure_, _Text_, _Hypertext_, e _List_ - facenti parte del gruppo _Core_ -, mentre l’XHTML Integration Set Document Type Conformance esclude Structure. Entrambe le conformità richiedono che i nuovi elementi ed attributi siano inclusi in un loro namespace, ma l’XHTML Family Module Conformance prevede restrizioni sulla modifica di elementi già specificati precedentemente in altri moduli.

Ma allora, perchè non usare XHTML 1.1?

Tornando alla domanda iniziale, quindi, è necessario chiarire alcuni punti (i più attenti se ne saranno accorti sicuramente):

  • XHTML 1.0 è un linguaggio di passaggio, ancora fortemente legato ad HTML. Non è modulare, e include tre DTD esattamente come HTML. Permette ancora l’utilizzo di molti tag deprecati e attributi a scopo presentazionale o dal contenuto semantico praticamente assente, ed ha quindi poco a che fare con XML, se non per la rigidità sintattica.

  • XHTML 1.1 consiste in un’evoluzione modulare di XHTML 1.0. Non ha più le tre dichiarazioni DTD classiche, ma potremmo dire che si rifà molto al set _Strict_ della sua versione precedente.

  • Il supporto ad XHTML è attualmente scadente nella maggior parte dei parser in circolazione. Per approndimenti (ma anche per curiosità) consiglio vivamente la lettura dell’articolo Attenti ad XHTML!, che ben riassume il concetto.

Detto questo, tirando qualche somma, posso concludere dicendo che l’uso di XHTML 1.1 è sconsigliato sia perchè attualmente potremmo usufruire solo di una minima parte delle sue potenzialità, sia perchè le specifiche sono ancora in fase di completamento (W3C Working Draft 16 February 2007), in seguito alla decisione di pubblicarne una seconda edizione modificata e depurata dai cosiddetti errata presenti nella precedente versione delle specifiche. Inoltre, consideriamo che attualmente è utopistico pensare a reali e concrete possibilità di personalizzazione e operazione sui moduli, in mancanza di applicazioni adeguate a supportare questa caratteristica.

E’ per questo motivo che è consigliato l’uso di XHTML 1.0 o persino HTML 4.01, dove se non altro la scelta si riduce a tre document types che il software disponibile mastica senza troppi problemi di incompatibilità, sebbene non ne possa tuttavia assaporare tutto il gusto.

Come sempre il vostro contributo è apprezzatissimo, quindi fatevi avanti. :)

Approfondimenti

L'articolo è stato di tuo gradimento? Puoi controllare che vi sia altro di tuo interesse nelle categorie e , oppure iscriverti al notiziario RSS e seguirmi su per restare sempre aggiornato sulle ultime pubblicazioni.

Pubblicato lunedì 07 maggio 2007.

Discussione [3]

  1. Kiko aggiunge:

    [Immagine] Segue l'intervento di Kiko

    Ero indeciso su quale documento leggere per capirne di più. Chiaro, diretto, preciso, pertinente! Devo aggiungere altro?

  2. Simone Onofri aggiunge:

    [Immagine] Segue l'intervento di Simone Onofri

    Personamlmente consiglio l'utilizzo di XHTML 1.0 Strict a meno che non si abbiano particolari esigenze, come ad esempio l'utilizzo di RDFa (un ottimo modo per integrare un livello semantico direttamente sull'XHTML a cui stiamo lavorando al W3). Non tanto perchè XHTML 1.1 non sia ancora una Raccomandazione a tutti gli effetti, sperimentare fa bene, ma per l'attuale scarso supporto da parte dei browser... e perchè, come tutte le cose, si usa solo se serve :)

  3. NoWhereMan aggiunge:

    [Immagine] Segue l'intervento di NoWhereMan

    Oh, bravo eKoes! :D un bel sunto per chi non ha tempo. Tipo me :D

Discuti

Il blog è in sola lettura.

Paginatura: