Ecologia dei siti web.it

5 dicembre 05

Le tecnologie troppo rigide sono contrarie allo spirito della rete?

di Maurizio Boscarol

Credete che XSL sia troppo difficile? Siete in buona compagnia. La pensano così anche Bert Bos e Håkon Wium Lie, non proprio gli ultimi arrivati. Sono infatti i creatori ufficiali delle specifiche CSS e del libro Cascading Style Sheets: Designing for the Web

Sebbene riconoscano che i CSS sono molto meno potenti di XSL da molti punti di vista (XSL è un vero e proprio linguaggio di programmazione, una macchina di Turing con cui si può fare virtualmente di tutto, mentre i CSS sono un semplice linguaggio per definire la presentazione visiva dei documenti html), ritengono che siano utilizzabili anche per compiti ben più complessi del gestire l’aspetto visivo delle pagine.

Per dimostrarlo hanno impaginato il loro libro proprio con i CSS, grazie ad un software (a pagamento) che hanno contribuito a creare: si tratta di Prince, e consente di utilizzare i fogli di stile per trasformare documenti XML di qualunque tipo (dunque anche XHTML) in PDF pronti per la stampa.

Grazie a Prince si possono estrarre informazioni, gestire note a più di pagina, layout multicolonne e immagini. Il software non è adatto a inesperti totali, perchè ha un’interfaccia a linea di comando e una installazione non completamente ovvia per i non esperti. Ma è un primo passo interessante per un altro motivo. Dimostra che i linguaggi troppo complicati e sofisticati hanno una vita difficile sul web. Il motivo a me pare semplice: più complicato dal punto di vista sintattico, grammaticale e semantico è un linguaggio, meno persone sono in grado di utilizzarlo. Dunque minori sono le probabilità che si diffondano sue applicazioni in un contesto di rete.

La tolleranza è di rigore sul web

Se ci pensate è così più o meno con tutte le tecnologie di maggior successo. Lo stesso XML, in generale, richiede più conoscenze del più semplice HTML, e difatti stenta ancora a diffondersi, e ad essere implementato con il rigore che le specifiche vorrebbero. HTTP non è certo il protocollo più sicuro e robusto, ma il più interoperabile sì. PHP è pieno di problemi (senza andare alle possibili vulnerabilità, pensiamo allo scarso supporto di Unicode, fra gli altri), mySql non è un campione di sicurezza dato che accetta chiamate multiple sullo stesso dato. Eppure, se questi limiti corrispondono ad una facilità di comprensione da parte dei non tecnici, ad una compatibilità ampia con tecnologie esistenti e ad un modello di diffusione basato sull’Open Source, il successo in termini di diffusione (non necessariamente di uso professionale) è molto più probabile rispetto a tecnologie rigorose, rigide, poco interoperabili e chiuse.

E’ difficile dire se questi fattori (facilità di apprendimento dai non esperti, tolleranza agli errori, interoperabilità, modello open) siano tutti ugualmente importanti o se ce n’è qualcuno che da solo fa la differenza: certo che la proposta di Bos e di Lie, se sviluppata, rischia di relegare ai soli esperti (e dunque marginalizzarla ancora) una tecnologia potenzialmente interessante ma molto dispendiosa come XSL. E se la forza del web fosse proprio nella sua scarsa formalità, nella sua tolleranza (sintattica, di formati, di produzione)?

Merita quantomeno rifletterci: se questo fosse vero, molti dei tentativi di normare e regolamentare rigidamente questo o quell’aspetto della produzione web sarebbero destinati ad un futuro difficile. Ma qual è il limite entro cui essere tolleranti è un pregio, e quando diventa, come nel caso della guerra dei browser, un serio problema?

La guerra dei browser e il futuro degli standard

Non c’è dubbio che la guerra dei browser è stato un momento poco felice (anche se a ben pensarci è coinciso con il massimo sviluppo del web, probabilmente non per suo merito) per gli sviluppatori. Ma è anche vero che questo fenomeno che chiamiamo guerra dei browser è stato determinato proprio dalle spinte contrarie a quelle che abbiamo evidenziato. Si deve infatti al tentativo di chiudere il supporto al prodotto concorrente, non ad aumentarlo. I browser hanno tentato di essere meno compatibili con le specifiche e di imporre un proprio modello. Questo non ha funzionato, ma a ben guardare è la conferma che difficilmente si riesce a conquistare completamente un mercato come la rete con politiche commerciali di chiusura. Potrebbe paradossalmente valere anche per gli standard: se questi diventassero troppo rigidi potremmo assistere al loro fallimento, anziché alla loro diffusione.

Gli standard rimangono importanti per garantire la compatibilità tecnica e l’uguale opportunità (di accesso e di produzione) per tutti, ma sono utili solo fino a che non sono usati per escludere qualcuno. In quel caso la loro adozione in un contesto di rete rischia di incontrare seri ostacoli, perché sarebbe contraria alle dinamiche stesse che sembrano regolare la rete. E’ un tema delicato e di interesse generale, che vedremo inevitabilmente sviluppato in futuro a tutti i livelli, da quello commerciale, a quello normativo, a quello politico.

Sezione: blog - Argomenti: (x)html, società |

Commenti:

  1. Marcolino    26 01 2006 - 21:56    # Io vengo dalla programmazione pura, e una delle cose più sconcertanti che ho trovato sul Web, era proprio la mancanza di una rigorosità.
    Mi rendo conto e apprezzo che questa rigorosità l’hanno chiamata semantica, che indubbiamente alimenta un discorso più ampio. E questo mi bata per lavorare.

    Quanto tempo si perde oggi per rendere un sito quanto più aderente alle specifiche di vari programmi, e quanto tempo ne guadagneremmo se tutto funzionasse a dovere.

    Tu parli di XSL, ma XSL non è difficile o meglio lo è per quelle persone che non vogliono perdere l’indubbia semplicità dei costrutti xhtml/css, ma non è meno difficile che implementare una classe nel framework del turbopascal, io ci ho messo mesi per capire la programmazione a oggetti, ma alla fine quello che facevo mi piaceva farlo.
  2. Maurizio Boscarol    1 02 2006 - 14:23    # Non dubito che un programmatore trovi il web poco rigoroso. Ma quello che il web ci dimostra è che le tecnologie che si sono diffuse di più sono proprio quelle meno rigide. Anche meno rigorose. Cioè, quello che appare è che la facilità di diffusione e di adozione a livello di massa sia più probabile con tecnologie in qualche modo imperfette.

    Il problema è il bilanciamento, il punto di equilibrio. Se c’è una babele di linguaggi che provoca incompatibilità, non ci può essere alcun sviluppo. Ma in rete la babele si arresta quasi spontaneamente, perchè è contraria allo sviluppo della rete stessa. Ed è un po’ quel che è successo con il movimento degli standard web, sentito proprio da alcuni sviluppatori. Era il momento di stoppare la guerra dei browser e di ridurre le incompatibilità.

    Questo però non significa che tutto dev’essere strict, né che XSL sarà il futuro, né che XHTML 2.0 sostituirà l’1.0. Succederà solo se i vantaggi saranno evidenti. Altrimenti la gente continuerà ad usare ciò che è utile, non ciò che è strict. Il pendolo oscillerà sempre fra i due estremi, tentando di evitare seri problemi di incompatibilità, così come eccessi di rigore che ridurrebbero la probabilità d’uso delle tecnologie, almeno a parità di utilità.
  3. Marcolino    4 02 2006 - 00:53    # Forse i motivi per cui si sono diffuse le tecnologie meno rigide, è perché si è voluto mantenere l’universalità del Web.
    Scrivere un file in HTML e lanciarlo nella rete è alla portata di tutti.

    Però è anche vero che siamo alla saturazione, inoltre è quasi impossibile oggi scrivere un motore di ricerca, in grado di mantenere un elenco di tutto.

    Intendo un elenco semanticamente corretto, non una lista della spesa.

    Le tecnologie rigide srvono più che altro a questo, è ovvio che se il mio sito si vede meglio con IE che con FF, non è che gliene fregherà molto a tutti, l’importante è che i contenuti siano almeno intelligibili.

    Ma Google, quale indicizzerà? Se leggiamo la sua guida, solo quelle pagine, mi verrebbe da dire: Well formed, perché si vuole dare un taglio ai Webmaster in erba o se preferisci agli spaghetti coder, termine che non mi piace.

    Quindi le tecnologie troppo rigide sono contrarie alla libertà della rete, pur restando nel breve termine e nel futuro, l’unica possibilità di far rimanere la rete usabile e sopratutto utile.
  4. Maurizio    9 02 2006 - 13:21    # Tu dici: “Forse i motivi per cui si sono diffuse le tecnologie meno rigide, è perché si è voluto mantenere l’universalità del Web.”

    Certo. E’ proprio quello che voglio sottolineare. Prima infatti esistevano altre tecnologie. Escludevano, non univano. La rete nasce per volontà di unire, e si basa su tecnologie “stupide”, basiche, che consentivano ai formati che già c’erano di sopravvivere. E’ questa la sua forza, l’idea di Berners-Lee.

    Francamente non vedo il problema dei motori di ricerca. Non credo che formalizzando si abbiano motori migliori. Google si basa sul ranking proprio per sfruttare le dinamiche di rete, non il formalismo di una qualche specifica. Se le pagine sono well formed, meglio ancora, perché ci sono maggiori informazioni. Ma se non lo sono si indicizza lo stesso.

    “Le tecnologie troppo rigide sono contrarie alla libertà della rete, pur restando nel breve termine e nel futuro, l’unica possibilità di far rimanere la rete usabile e sopratutto utile.”?

    Non lo credo. La rete utile è qualcosa che è offre vantaggi alle persone. La rete utile è Amazon, è E-bay, sono i blog per chi è interessato, sono i siti di contenuto amatoriali, così come quelli professionali, perché ci danno modo di conoscere cose.

    Il contenuto e il servizio rendono la rete utile, non il rigore tecnologico, laddove questo non è necessario. Il rigore tecnologico è utile alle nicchie, a scopi specifici. Se si impone il rigore e si ottiene di ridurre drasticamente il bacino d’utenza, ebbene, perderò molti dei vantaggi dall’avere una rete.

    C’è un limite al caos tollerabile, ma c’è pure un limite al rigore ottenibile. Entrambi gli eccessi portano all’inutilità, per ragioni diverse.

I commenti sono chiusi per questo articolo.