Questo è il primo di una serie di articoli dedicati al formato RSS e alle sue applicazioni. Come per molte delle cose che nascono su e per la Rete, il campo vede schierati agli estremi scettici ed entusiasti, con in mezzo la folla di quelli che prima di esprimere un giudizio vorrebbero capire su cosa darlo. Personalmente, non penso sia la next big thing, l'ennesima rivoluzione (magari solo annunciata). Sono però convinto che rappresenti uno strumento potente e versatile per veicolare contenuti sul web e che perciò valga la pena saperne di più.
L'inizio è 'teorico'. In questa prima parte ci limiteremo, infatti, a tracciare le linee generali, per poi scendere nei dettagli negli articoli seguenti. In essi analizzeremo di RSS gli aspetti relativi alla produzione, alla diffusione/distribuzione e alla fruizione. Smanettoni e amanti del codice non scappino: avranno pane fresco e buono da mangiare;-). Così, non ci abbandoni subito chi sta solo cercando la dritta per un buon news aggregator: abbiamo pensato anche a voi!
Definizioni di base (per capire cos'è)
Partiamo subito con una prima definizione di orientamento: «RSS è un formato per la distribuzione di contenuti sul Web».
È una definizione volutamente ampia, generica, ma che guarda avanti, rimanendo
aperta agli sviluppi possibili (e in parte già esplorati) di questa tecnologia.
In realtà, spulciando tra i tanti tutorial reperibili in Rete, potreste imbattervi in definizioni più restrittive che suonano più o meno così: «RSS è un formato per la distribuzione e la diffusione su diversi canali (syndication) di liste di link, titoli e sommari di news».
Nulla da eccepire. Si può usare RSS anche per fare questo. Anzi, come vedremo, il linguaggio è nato essenzialmente per svolgere questa funzione e così viene usato da molti siti giornalistici o di news. Soltanto che, ribadisco, è solo uno degli usi possibili.
Cambiamo versante e buttiamoci sul tecnico: come linguaggio, RSS è un'applicazione di XML.
In base a ciò, un documento RSS deve essere conforme alla specifica XML 1.0 ed essere pertanto ben formato (per il concetto di documento ben formato riamandiamo alla guida a XML). A beneficio di chi non mastica tutto il giorno tecnicismi astrusi, dirò che il rapporto tra RSS e XML può essere paragonato a quello tra una lingua ufficiale e standardizzata con un suo dialetto. Un rapporto a dire il vero un po' speciale e difficilmente verificabile nella realtà 'linguistica', ma basti come schema orientativo: RSS è un dialetto con un lessico tutto suo (molto limitato peraltro), ma deve rigorosamente rispettare la sintassi e la grammatica di XML. In pratica: posso usare tranquillamente i termini del veneto o del napoletano, ma guai a toppare un congiuntivo, una consecutio temporum o un è senza accento. L'Accademia della Crusca, che per noi è il W3C, ha deciso così e dobbiamo adeguarci.
Esplorazioni lessicali (per capire a cosa serve)
Per collocarlo nel giusto contesto applicativo, ritengo utile un esercizio di confronto tra RSS e i sistemi tradizionali di comunicazione (in Rete e non). Mi sono messo su questo strada sin dall'inizio, scandendo la scaletta degli articoli. Ho parlato di produzione, diffusione e fruizione.
L'esercizio si può innescare anche partendo da una rapida ricognizione delle parole associate comunemente a RSS. Pensate a syndication, feed, channel. Tutti termini lessicalmente derivati dalla pratica e dal linguaggio dei media tradizionali. Lo spunto è tratto da questo articolo di Mark Nottingham. Tra le tante cose interessanti, riporta le definizioni dei tre termini di sopra.
Syndication:
To sell (a comic strip or column, for example) through a syndicate for
simultaneous publication in newspapers or periodicals.
È una pratica nota a chi conosce l'ambiente. Ne parla brevemente qui Luisa Carrada:
Sta prendendo piede anche in Europa il modello syndication, cioè
l'affidamento dei testi a un'agenzia che provvede a distribuirli a siti e riviste.
La parola è usata anche per un sistema di collaborazione e collegamento tra reti televisive o radiofoniche. Una rete produce un programma e poi lo distribuisce su un certo numero di stazioni locali.
Il concetto centrale, qui, è quello della redistribuzione e del riuso dei contenuti. Sotto questa luce RSS si propone come una delle basi di qualunque sistema di content management. È facile. È estensibile. E ci posso fare quello che voglio. Metterne i contenuti su un portale o sul mio weblog. Mandarli per e-mail o con un fax, o farci un PDF. Produco una cosa e la diffondo in dieci forme. Una specie di petrolio dell'informazione online. Syndication. Credo che per chi si occupa di comunicazione in Rete sia una cosa da tener presente. E penso pure che un sito informativo rispettabile (telematicamente parlando) debba avere tra le sue opzioni di consultazione anche questa. Lo fanno molto bene, per fare un esempio, al Christian Science Monitor. Se ne parla in questo articolo di J. D. Lasica, ottimo come analisi delle relazioni tra RSS e giornalismo.
Anche la definizione di feed ci porta nell'ambito dei media tradizionali:
The transmission or conveyance of a local radio or television program, as by satellite, on the Internet, or by broadcast over a network of stations.
E quella di 'canale' ha bisogno di poche spiegazioni:
A course or pathway through which information is transmitted.
Da qui all'estendere la metafora e proporre un parallelismo tra un canale RSS e uno televisivo il passo è breve. Chi produce un feed (anche HTML.it ha i suoi feed rss) invia un flusso di news (item) che sono come le trasmissioni che si succedono nell'arco di una giornata. E, guarda caso, per indicare l'aggiunta di un feed al news aggregator, si usa il termine 'subscription' (abbonamento o sottoscrizione), esattamente quello che si userebbe per una pay TV o una rivista.
Una delle prime aziende a comprendere le potenzialità di questa strategia e di RSS è stata Moreover. Fornisce feed di news (anche gratuiti) a migliaia di siti, anche se il business vero è quello che fa con il mercato aziendale.
Èun processo che parte dalla caccia alla notizia, passa attraverso la classificazione e la conversione in XML e si conclude con la pubblicazione in vari formati e su diversi supporti.
Il panorama, però, sta cambiando radicalmente. Il ruolo di mediazione delle aziende alla Moreover è attaccato su due fronti. I siti di informazione (compresi i weblog personali) producono direttamente i loro feed RSS e li rendono pubblici. Prima era necessaria l'opera di 'traduzione' da HTML a RSS (in gergo si chiama scraping). Inoltre, l'introduzione di 'lettori' o 'interpreti' di documenti RSS (i news aggregator) consente a chiunque di attingere direttamente alla fonte: che bisogno ho di Moreover se posso crearmi la mia selezione personale di news e fonti informative da consultare in un programma ad hoc? E se un sito non produce RSS? Facile. Ci sono aggregatori che fanno benissimo quell'opera di conversione di cui si è parlato ed esistono anche tool dedicati. Ma di questo parleremo diffusamente nei prossimi articoli.
Un po' di storia (per capire da dove viene)
Qui entriamo in un terreno un po' intricato. Come molte cose dell'informatica, anche la storia di RSS è fatta di rivalità, piccole ripicche, gruppi contrapposti. Il formato venne creato da Netscape, che nel 1999 produsse la versione 0.90. Erano gli anni in cui l'azienda puntava molto sulla creazione di portali personalizzati (MyNetscape) da riempire con liste di link o di news selezionate dall'utente in base alle sue preferenze o esigenze. Seguì una versione più semplificata, la 0.91. Netscape abbandonò ben presto l'avventura e con essa lo sviluppo di RSS.
Il formato venne allora adottato da Dave Winer come base dei sistemi di content management di Userland. Intanto, un gruppo di sviluppatori iniziò a lavorare su un altro formato di syndication, fondato su uno dei linguaggi standard del W3C, RDF. Ne venne fuori la specifica RSS 1.0 (RDF Site Summary).
Sentitosi scavalcato e deprecando certi aspetti di complessità di RSS 1.0, Dave Winer proseguì per la sua via, dando nuova vita al vecchio formato e sfornando, nell'ordine le versioni RSS 0.92, 0.93, 0.94, fino a quella attuale, rilasciata da pochi mesi: RSS 2.0. Per rimarcare la distanza da RSS 1.0 e sottolineare il carattere di semplicità della sua proposta, Winer ha dato al suo formato il nome di Really Simple Syndication.
La situazione, dunque, è che abbiamo due formati concorrenti per fare essenzialmente la stessa cosa. In effetti, negli elementi di base, sono uguali. Cambia la filosofia di fondo. RSS 2.0 punta alla semplicità, RSS 1.0 guarda alla ricchezza semantica e all'estendibilità con moduli esterni (cose comunque possibili anche per il rivale). Un'utile tabella di confronto tra le diverse versioni la trovate in questo articolo di Mark Pilgrim.
Quanto alla diffusione, non dobbiamo pensare che le versioni attualmente superate siano scomparse. I feed in formato RSS 0.91 o 0.92 sono molto utilizzati, principalmente per la loro semplicità e per il fatto di essere più che sufficienti per una syndication di base, ridotta all'essenziale.
Chi deve preoccuparsi per la presenza di proposte contrapposte? Non chi consuma RSS con i news aggregator: sono in grado di leggere tranquillamente tutti i formati. Se ne deve preoccupare, invece, il programmatore che voglia, per esempio, trasformare un feed. I due linguaggi presentano sintassi diverse e per garantire compatibilità bisogna per forza creare meccanismi o script che ne tengano conto. Dal lato della produzione, dovrebbe preoccuparsene chi intenda fare di un feed un uso appena più avanzato della syndication di base. A quel punto è opportuno valutare con attenzione cosa offrono i due formati.
Un primo esempio (per capire com'è fatto)
A questo punto possiamo dare un primo sguardo ad un semplice modello di feed RSS. Ho usato come schema un documento RSS 0.91. È il formato più semplice
e minimale e partendo da qui potremo meglio capire gli sviluppi successivi:
<?xml version="1.0" ?>
<rss version="0.91">
<channel>
<title>HTML.it News</title>
<link>
http://webnews.html.it/</link>
<description>Le News di HTML.it sul mondo Hi-Tech</description>
<item>
<title>Italiani: senza fili e senza banda</title>
<link>
http://webnews.html.it/news/1066.htm</link>
<description>L'Italia si conferma il paese europeo con la maggior presenza di telefonini. Tutt'altra storia, invece, per la banda larga.</description>
</item>
</channel>
</rss>Ricordate? RSS è un'applicazione XML. Pertanto, un feed può presentare (non è obbligatorio) il classico prologo tipico di questo linguaggio (in arancione).
Segue (in giallo) l'obbligatorio elemento radice. È quello
che deve contenere tutti gli altri elementi.
Subito dopo viene dichiarato l'elemento <channel> con i suoi sottoelementi (in verde). Quelli richiesti sono tre e definiscono le informazioni essenziali sul canale: <title> definisce il nome, <link> il suo URL, <description> fornisce una descrizione sintetica. Ho usato l'espressione 'informazioni sul canalÈ, perché il contenuto di un feed RSS non corrisponde necessariamente a quello di un sito in generale. Un giornale online, ad esempio, può avere feed RSS per le sezioni Esteri e Sport, oltre che per i titoli di testa. In tal caso va indicato l'URL della sezione e non del sito.
All'interno di <channel>, trovano posto i vari <item> che compongono un feed: corrispondono ai post di un weblog, alle notizie di un sito di news, etc. La gestione di un singolo item (cosa pubblicare e come) è riservata all'autore. Si può decidere di fornire solo l'URL e il titolo, per esempio. O aggiungere una 'descrizionÈ. Questa potrà essere una sintesi di un articolo, un estratto contenente solo la prima parte o il testo completo. Nessuno di questi elementi è obbligatorio, ma lo schema tipico è quello riportato qui sopra. Altri metadati possono arricchire l'informazione: l'autore, la data di pubblicazione, la categoria o l'ambito semantico di appartenza, etc. Il numero di item presenti in un feed, infine, è una libera scelta dell'autore.
Come si vede, tutto è estremamente semplice. Un feed RSS non fa altro che definire un 'canalÈ con i vari item che lo compongono. Ora ragioniamo un momento insieme. L'esempio dovrebbe far comprendere che RSS non è solo buono per veicolare news o i contenuti di un weblog (per i quali è il formato naturale). Si propone, invece, come strumento versatile, adatto per tutti i dati che possano essere facilmente serializzati o organizzati come liste. Posso fare un feed con la Top Ten dei CD più venduti, per una lista di offerte di lavoro, per un bookmark, per un calendario di riunioni o conferenze. Ecco perché la prima definizione è quella più aderente alle potenzialità di RSS.
Credo anche che l'esempio sia utile per chiarire a tutti le differenze di fondo tra RSS (e tutti i linguaggi 'semantici') e HTML. In che cosa sono confrontabili? In poco. Entrambi sono formati per distribuire contenuti. Entrambi sono linguaggi di markup. In quanto tali, hanno marcatori (tag o elementi) che definiscono il modo in cui un documento dovrà essere interpretato. Il markup di HTML è fatto per essere interpretato dai nostri browser. Di un documento definisce la struttura, al limite la presentazione. In RSS, invece, i marcatori sono autoesplicanti. Mi dicono chiaramente di cosa si parla. Sono comprensibili per un uomo e non solo per una macchina. L'esempio qui sotto dovrebbe chiarire.
Questo è un frammento di codice HTML:
<h1>Marziani su Roma</h1>
<p>Un'astronave di extraterrestri è atterrata nella Capitale.</p>Questo un pezzo di RSS:
<title>Marziani su Roma</title>
<description>Un'astronave di extraterrestri è atterrata nella Capitale.</description>Cosa vuol dire <h1>? Per me niente. Mozilla invece lo capisce. Quando lo incontra formatterà il testo in un certo modo, più grande ed evidente rispetto al resto. Struttura e presentazone. Il marcatore <title> invece parla da sé, lo comprendiamo: quello è il titolo, diciamo, di un articolo o del post di un weblog. Semantica. Purtroppo, ai browser quel <title> non dice niente. Lui intende solo <h1> e quindi lo ignorerà. È comunque scusato: è stato creato per fare un'altra cosa. Per visualizzare un documento RSS in un browser tradizionale, non ci rimane che usare dei sistemi per trasformare <title> in <h1>. La scelta tra i linguaggi di scripting è vasta e varia.
Uno sguardo alle specifiche
Per concludere questo primo articolo, diamo uno sguardo più ravvicinato alle due specifiche attualmente riconosciute come ufficiali. Un primo caveat per chi ha intenzione di approfondire l'argomento da programmatore. Immaginate di voler fare uno script per trasformare in HTML un feed RSS o viceversa. Qualunque linguaggio usiate dovrete tenere conto delle differenze sintattiche tra le due specifiche. L'approccio è ben spiegato nell'articolo di Mark Pilgrim citato in precedenza, dove l'autore illustra la procedura per trasformare un feed RSS con Python.
Per un approfondimento sui vari elementi che è possibile inserire in un documento vi rimando alla consultazione diretta delle specifiche. Qui mi interessa osservare insieme i due documenti, cercando di comprenderne affinità e differenze. Ho cercato di agevolare il compito riproducendo lo schema a colori visto qui sopra e inserendo delle note di commento.
Se trascurate i dettagli e vi concentrate sugli elementi essenziali, avrete l'impressione di due formati pressocché identici. Gli elementi di base sono uguali e la loro 'semantica' pure. Le divergenze emergono posando l'occhio sui dettagli.
1. RSS 1.0 è più complesso, Mark Pilgrim dice 'più verboso'. RSS 2.0 è indubbiamente più intuitivo.
2. RSS 1.0, anche nelle sue applicazioni di base, fa un uso esteso dei Namespace. È nato per essere 'modularÈ. Cercherò di essere comprensibile. Questo formato ha un set molto limitato di elementi. Per esempio, al livello dell'elemento <item>, prevede solo tre sottoelementi: <link>, <title>, <description>. Nel documento di esempio potete osservare che ho aggiunto, però, anche altri dati: una 'categoria' (<dc:subject>), l'autore (<dc:creator>), la data di pubblicazione (<dc:date>). Potevo benissimo farne a meno, ma per me è una cosa buona inserirli. Notate, poi, che i nomi di questi tre elementi sono preceduti da un prefisso e dai due punti: dc:. Significa che questi elementi non fanno parte della specifica di base, ma appartengono ad un altro linguaggio, esattamente al modulo Dublin Core. Il parser che andrà a interpretare il documento deve saperlo e il prefisso serve a questo. È come se dicessi: "Caro parser, guarda che <dc:date> appartiene al Dublin Core. Hai notato il prefisso?". E dato che i parser vanno facilmente in confusione, quando in XML si usano Namespace esterni è obbligatorio dichiararlo all'inizio del documento. Se ci fate caso, l'ho fatto:
<rdf:RDF
xmlns="http://purl.org/rss/1.0/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/">Guardate l'ultima riga. Significa più o meno: "Caro parser, guarda che ho intenzione di usare elementi del Dublin Core. Stai attento, sono quelli che iniziano con dc:.". La prima riga, invece, dopo la dichiarazione del Namespace (xmlns) non presenta alcun prefisso. L'URL punta alla specifica RSS 1.0. Il mio bravo parser, ormai ben istruito, capirà che gli elementi senza prefisso (come <title>) appartengono ad RSS 1.0. Un altro Namespace che troverete sempre in un documento RSS 1.0 è quello di RDF.
Per approfondimenti sugli argomenti qui appena sfiorati vi rimando alla lista delle risorse alla fine dell'articolo.
3. Detto questo, è facile capire come RSS 2.0 preferisca all'uso esteso di moduli soluzioni 'internÈ. Anche nel secondo esempio ho usato metadati su categoria, autore e data, ma tutti e tre gli elementi sono previsti dalla specifica. Che, come si può intuire, ha un numero maggiore di elementi rispetto a RSS 1.0. Inoltre, in RSS 2.0 non abbiamo bisogno di definire un Namespace
predefinito.
4. Entrambi i formati, comunque, sono modulari. La modularità è un concetto fondamentale in XML. È la via verso la libertà. Posso aggiungere tranquillamente nuovi elementi per qualsiasi esigenza. Perdonatemi, ma vi tocca un'altra metafora. Pensate ad RSS come ad una macchina molto spartana, con quattro ruote, un motore e una carrozzeria minimale. Per spostarmi da casa al lavoro va benissimo. E se un giorno piove? No problem: aggiungo il 'modulo' tettoia. Se fa caldo? Inserisco il 'modulo' aria condizionata. Quando non mi servono li ritolgo. Ecco, il Dublin Core o qualunque altro modulo, sono come la tettoia o l'aria condizionata.
5. Una differenza importante sta nella diversità dell'elemento radice: <rdf:RDF> per RSS 1.0, <rss version="2.0"> per RSS 2.0
6. Osservate nei due esempi la collocazione delle righe verdi. In RSS 1.0 l'elemento <channel> è al di fuori degli item, in RSS 2.0
li comprende al suo interno.
7. RSS 1.0 presenta all'interno di <channel> una lista con gli URL dei vari item, compresa nell'elemento <items>.
E per questo primo articolo siamo giunti alla fine. Per commenti, suggerimenti e critiche lo spazio è sempre aperto. La prossima volta ci metteremo nei panni di chi vuole dotare il suo sito di un magnifico feed RSS. Vedremo i tanti modi con cui potrà realizzare il suo desiderio.
Linkografia (per approfondire)
Specifiche ufficiali
Articoli e tutorial introduttivi
News that comes to you - J.D. Lasica sulla Online Journalism Review
What is RSS - Mark Pilgrim su Xml.com
RSS Workshop - Utah University
The Evolution
of RSS - WebReference
Approfondimenti
RDF per descrivere il Web - Articolo introduttivo su RDF
