Architettura del World Wide Web, Volume Uno

Elenco di Principi, Vincoli, e Note di Buona Prassi

I seguenti principi, vincoli, e note di buona prassi sono trattate in questo documento ed elencate qui per comodità. Esiste anche un sommario a sé stante.

Identificazione

• Identificatori Globali (principio, 2)
• Identificare con gli URI (prassi, 2.1)
• Gli URI identificano una Singola Risorsa (vincolo, 2.2)
• Evitare gli alias dell'URI (prassi, 2.3.1)
• Utilizzo consistente dell'URI (prassi, 2.3.1)
• Riutilizzo degli schemi di URI (prassi, 2.4)
• Opacità dell'URI (prassi, 2.5)

Interazione

• Riutilizzo dei formati di rappresentazione (prassi, 3.2)
• Inconsistenza dati-metadati (vincolo, 3.3)
• Associazione di metadati (prassi, 3.3)
• Reperimento sicuro (principio, 3.4)
• Rappresentazione disponibile (prassi, 3.5)
• Fare un riferimento non implica seguire quel riferimento (principio, 3.5)
• Rappresentazione consistente (prassi, 3.5.1)

Formati di Dati

• Informazione sulla versione (prassi, 4.2.1)
• Linea di condotta per il namespace (prassi, 4.2.2)
• Meccanismi di estensibilità (prassi, 4.2.3)
• Conformità dell'estensibilità (prassi, 4.2.3)
• Estensioni sconosciute (prassi, 4.2.3)
• Separazione fra contenuto, presentazione, interazione (prassi, 4.3)
• Identificazione del collegamento (prassi, 4.4)
• Collegare il Web (prassi, 4.4)
• URI generici (prassi, 4.4)
• Collegamenti ipertestuali (prassi, 4.4)
• Adozione del namespace (prassi, 4.5.3)
• Documenti del namespace (prassi, 4.5.4)
• QName indistinguibili dagli URI (vincolo, 4.5.5)
• Dare corrispondenze ai QName (prassi, 4.5.5)
• XML e "text/*" (prassi, 4.5.7)
• XML e codifiche di carattere (prassi, 4.5.7)

Principi generali di Architettura

• Ortogonalità (principio, 5.1)
• Recupero dell'errore (principio, 5.3)

1.1. Riguardo questo Documento

Questo documento descrive le proprietà che desideriamo per il Web e le scelte di progettazione che sono state fatte per conseguirle. Esso promuove il riutilizzo degli standard esistenti quando adattabili e fornisce una guida su come innovare in maniera consistente con l'architettura del Web.

I termini DEVE, NON DEVE, DOVREBBE, NON DOVREBBE e POTREBBE sono impiegati nei principi, nei vincoli e nelle note di buona prassi in conformità alla RFC 2119 [RFC2119].

Questo documento non include condizioni di conformità per queste ragioni:

• Si prefigura che il software conforme sia così vario che non sarebbe di giovamento essere in grado di riferirsi alla categoria degli agenti di software conforme.
• Qualcuna delle note di buona prassi riguardano persone; le specifiche, generalmente, definiscono la conformità per il software, non per le persone.
• Non crediamo che l'aggiunta di una sezione per la conformità porti verosimilmente a incrementare l'utilità del documento.

2.1. Benefici degli URI

La scelta di una sintassi per gli identificatori globali è qualcosa di arbitrario; è il loro scopo globale ad essere importante. L' Identificatore Uniforme di Risorsa, {Uniform Resource Identifier} [URI], è stato impiegato con successo sin dalla creazione del Web. Esistono benefici sostanziali nel partecipare alla rete esistente di URI, fra questi i collegamenti, i bookmark, la cache e l'indicizzazione da parte dei motori di ricerca, ed esistono costi non indifferenti nel creare un nuovo sistema di identificazione che abbia le stesse proprietà degli URI.

Una risorsa dovrebbe avere un URI associato se un'altra parte potrebbe ragionevolmente voler creare un collegamento ipertestuale ad esso; fare o rifiutare asserzioni al loro riguardo, reperire o mettere in cache una rappresentazione di essa, includerla tutta o in parte attraverso un riferimento a un'altra rappresentazione, annotarla o compiere altre operazioni su di essa. Gli sviluppatori del software dovrebbero aspettarsi che condividere gli URI tra le varie applicazioni sarà di grande utilità, perfino se questa stessa utilità non sia evidente fin da subito. La conclusione del TAG "URI, Indirizzabilità e l'uso di GET e POST in HTTP" tratta dei benefici aggiuntivi e delle considerazioni sull'indirizzabilità dell'URI.

Note: Alcuni schemi di URI (come la specifica per lo schema URI di "ftp") usano il termine "designare" dove questo documento usa "identificare".

2.2. Relazioni URI/Risorsa

Per definizione un URI identifica una sola risorsa. Non limitiamo l'ambito di cosa potrebbe essere una risorsa. Il termine "risorsa" è impiegato in un senso generale per qualunque cosa possa essere identificata da un URI. È convenzionale nel Web ipertestuale descrivere pagine Web, immagini, cataloghi di prodotti, etc. come "risorse". Il carattere peculiare di queste risorse è che tutte le loro caratteristiche essenziali possono essere convogliate in un messaggio. Identifichiamo questo insieme come “risorse informative”.

Questo documento è un esempio di una risorsa informativa. Esso consiste in parole e simboli d'interpunzione e grafica e altri artefatti che possono essere codificati, con vari gradi di fedeltà, in una sequenza di bit. Non esiste nulla rispetto all'informazione essenziale contenuto di questo documento che non può in principio essere trasferito in un messaggio. Nel caso del presente documento, il messaggio in carico è la rappresentazione di questo documento.

Comunque, il nostro uso del termine risorsa è intenzionalmente più esteso. Anche altre cose, come le automobili e i cani (e, se avete stampato questo documento su fogli di carta fisici, l'artefatto che state tenendo nelle vostre mani), sono risorse. Non sono risorse informative, in ogni caso, perché la loro essenza non è l'informazione. Sebbene sia possibile descrivere un gran numero di cose riguardo a un'automobile o a un cane in una sequenza di bit, la somma di quelle cose sarà invariabilmente un'approssimazione del carattere essenziale della risorsa.

Definiamo il termine “risorsa informativa” perché osserviamo che è utile nelle discussioni sulla tecnologia Web e potrebbe essere utile nel costruire specifiche per strutture adibite all'uso sul Web.

Dal momento che l'ambito di un URI è globale, la risorsa identificata da un URI non dipende dal contesto nel quale gli URI compaiono (si veda anche la sezione sulle identificazioni indirette (§2.2.3)).

[URI] è un accordo riguardo al come la comunità Internet allochi i nomi e al come li associ alle risorse che essi identificano. Gli URI sono divisi in schemi (§2.4) che definiscono, per il tramite della loro specifica di schema, il meccanismo per il quale identificatori di schemi specifici sono associati con le risorse. Per esempio, lo schema URI per "http" ([RFC2616]) usa server HTTP DNS e basati su TCP con il proposito dell'allocazione e la risoluzione dell'identificatore. Come risultato, identificatori come "http://example.com/somepath#someFrag" spesso assumono significato attraverso l'esperienza della comunità nel compiere una richiesta GET in HTTP sull'identificatore e, se fornito un responso positivo, interpretando il responso come una rappresentazione della risorsa identificata. (Si veda anche Identificatori di Frammento (§2.6).) Naturalmente, un'azione di reperimento come GET non è l'unico modo per ottenere informazione in merito ad una risorsa. Si potrebbe anche pubblicare un documento che abbia la pretesa di definire il significato di un particolare URI. Queste altre fonti di informazione potrebbero suggerire significati per tali identificatori, ma è una decisione dettata da una condotta locale, se si dovesse dar retta a quei suggerimenti.

Proprio come qualcuno potrebbe voler riferirsi ad una persona con nomi differenti (per nome e cognome, solo per cognome, per soprannome sportivo o affettuoso, e così via), l'architettura Web permette l'associazione di più di un unico URI con una risorsa. Gli URI che identificano la stessa risorsa sono chiamati alias di URI. La sezione sugli alias di URI (§2.3.1) tratta alcuni dei costi potenziali nel creare molteplici URI per la stessa risorsa.

Alcune sezioni di questo documento pongono domande circa la relazione fra URI e risorse, tra cui:

• Quanto posso desumere riguardo a una risorsa attraverso l'ispezione di un URI che la identifica? Si vedano le sezioni sugli schemi degli URI (§2.4) e l'opacità dell'URI (§2.5).
• Chi determina quale risorsa identifica un URI? Si veda la sezione sull'allocazione dell'URI (§2.2.2).
• La risorsa identificata da un URI, può cambiare nel tempo? Si vedano le sezioni sulla persistenza degli URI (§3.5.1) e la gestione della rappresentazione (§3.5).
• Dal momento che più di un solo URI può identificare la stessa risorsa, come so quali URI identificano la stessa risorsa? Si vedano le sezioni sulla comparazione di URI (§2.3) e sull'affermazione che due URI identificano la stessa risorsa (§2.7.2).

2.3. Comparazione di URI

Gli URI che sono identici, carattere per carattere, si riferiscono alla stessa risorsa. Poiché l'Architettura Web permette l'associazione di molteplici URI con una data risorsa, due URI che non sono identici alla lettera potrebbero ancora riferirsi alla stessa risorsa. URI differenti non necessariamente si riferiscono a risorse differenti, ma in genere c'è un elevato costo computazionale nel determinare che URI differenti si riferiscono alla stessa risorsa.

Per ridurre il rischio di un falso negativo (cioè, una conclusione errata che due URI non si riferiscono alla stessa risorsa) o un falso positivo (cioè, una conclusione errata che due URI si riferiscono alla stessa risorsa), alcune specifiche descrivono test di equivalenza in aggiunta alla comparazione carattere per carattere. Gli agenti che traggono conclusioni basate su comparazioni non autorizzate dalle relative specifiche si assumono la responsabilità per qualsiasi problema che ne derivi; si veda la sezione sulla gestione dell'errore (§5.3) per maggiori informazioni riguardo il comportamento responsabile quando si traggono conclusioni non autorizzate. La sezione 6 di [URI] fornisce maggiori informazioni riguardo la comparazione degli URI e la riduzione del rischio di falsi negativi e falsi positivi.

Si veda anche l'affermazione che due URI identificano la stessa risorsa (§2.7.2).

2.4. Schemi di URI

Nell'URI "http://weather.example.com/", l'"http" che appare prima dei due punti (":") designa uno schema di URI. Ogni schema di URI ha una specifica che spiega i suoi dettagli peculiari di come gli identificatori di schema sono allocati e vengono associati a una risorsa. La sintassi dell'URI è in questo modo un sistema di assegnazione dei nomi {naming} federato ed estensibile in cui ogni specifica dello schema potrebbe successivamente restringere la sintassi e la semantica degli identificatori all'interno di quello schema.

Esempi di URI da vari schemi includono:

• mailto:[email protected]
• ftp://example.org/aDirectory/aFile
• news:comp.infosystems.www
• tel:+1-816-555-1212
• ldap://ldap.example.org/c=GB?objectClass?one
• urn:oasis:names:tc:entity:xmlns:xml:catalog

Sebbene l'architettura Web permetta la definizione di nuovi schemi, introdurre un nuovo schema è dispendioso. Molti aspetti dell'elaborazione dell'URI sono dipendenti dallo schema e una gran quantità di software impiegato già elabora gli URI di schemi ben conosciuti. Introdurre un nuovo schema di URI richiede lo sviluppo e l'impiego non solo del software client per trattare lo schema, ma anche di agenti ausiliari come gateway, proxy e cache. Si veda [RFC2718] per altre considerazioni e costi relativi alla progettazione degli schemi di URI.

A causa di questi costi, se esiste uno schema di URI che incontra le necessità di un applicativo, i progettisti dovrebbero usarlo piuttosto che inventarne uno.

Consideriamo il nostro scenario di viaggio: l'agente che fornsice informazioni riguardo al tempo di Oaxaca dovrebbe registrare un nuovo schema di URI per il "meteo" per l'identificazione di risorse relative al tempo? Loro potrebbero quindi pubblicare URI come "weather://travel.example.com/oaxaca". Quando un agente software segue il riferimento di un tale URI, se ciò che accade in realtà è che un GET HTTP viene invocato per reperire una rappresentazione della risorsa, allora un URI "http" dovrebbe bastare.

2.5. Opacità dell'URI

Si sta tentando di indovinare la natura di una risorsa con l'ispezione di un URI che lo identifica. Tuttavia, il Web è progettato in modo che gli agenti comunichino lo stato dell'informazione della risorsa attraverso rappresentazioni, non identificatori. In generale, non si può determinare il tipo di una rappresentazione di risorsa ispezionando un URI della risorsa stessa. Ad esempio, l'"html" alla fine di "http://example.com/page.html" non fornisce alcuna garanzia che le rappresentazioni della risorsa identificata saranno servite con il tipo di media per Internet "text/html". Colui che pubblica è libero di allocare identificatori e definire come essi debbano essere serviti. Il protocollo HTTP non vincola il tipo di media per Internet basato sul componente di percorso dell'URI; il proprietario dell'URI è libero di configurare il server a restituire una rappresentazione usando PNG o qualsiasi altro formato di dati.

Lo stato della risorsa potrebbe evolvere nel tempo. Richiedere a un proprietario di URI di pubblicare un nuovo URI per ogni modifica nello stato della risorsa condurrebbe a un numero significativo di riferimenti spezzati. Per robustezza, l'architettura Web promuove l'indipendenza fra un identificatore e lo stato della risorsa identificata.

In pratica, sono poche le deduzioni che possono esser fatte poiché esse sono esplicitamente autorizzate dalle relative specifiche. Alcune di queste deduzioni sono trattate nei dettagli per reperire una rappresentazione (§3.1.1).

L'URI d'esempio utilizzato nello scenario di viaggio ("http://weather.example.com/oaxaca") suggerisce a un lettore umano che la risorsa identificata ha qualcosa a che fare con il tempo a Oaxaca. Un sito che riferisca del tempo a Oaxaca potrebbe essere identificato proprio facilmente dall'URI "http://vjc.example.com/315". E l'URI "http://weather.example.com/vancouver" potrebbe identificare la risorsa "il mio album di foto".

D'altro canto, l'URI "mailto:[email protected]" indica che l'URI si riferisce a una casella di posta. La specifica di schema di URI per "mailto" autorizza gli agenti a dedurre che gli URI in questa forma identificano caselle di posta su Internet.

Alcune autorità di assegnazione di URI documentano e pubblicano i le loro politiche di assegnazione di URI. Per informazioni aggiuntive riguardo l'opacità di URI, si vedano le questioni del TAG metaDataInURI-31 e siteData-36.

2.6. Identificatori di frammento

L'identificatore di frammento componente di un URI permette l'identificazione indiretta di una risorsa secondaria attraverso il riferimento a una risorsa primaria e a informazioni identificative aggiuntive. La risorsa secondaria potrebbe essere una porzione o un sottoinsieme della risorsa primaria, qualche panoramica sulle rappresentazioni della risorsa primaria o qualche altra risorsa definita o descritta da quelle rappresentazioni. I termini "risorsa primaria" e "risorsa secondaria" sono definiti nella sezione 3.5 di [URI].

I termini "primaria" e "secondaria" in questo contesto non limitano la natura della risorsa — non sono classi. In questo contesto, primaria e secondaria indicano semplicemente che esiste una relazione fra le risorse per gli scopi di un unico URI: l'URI con un identificatore di frammento. Qualsiasi risorsa può identificarsi come una risorsa secondaria. Potrebbe anche essere identificata impiegando un URI senza un identifcatore di frammento e una risorsa potrebbe essere identificata come una risorsa secondaria attraverso molteplici URI. Il fine di questi termini è porre l'attenzione sulla relazione fra le risorse stesse, non limitare la natura di una risorsa.

L'interpretazione degli identificatori di frammento è trattata nella sezione sui tipi di media e la semantica dell'identificatore di frammento (§3.2.1).

Si veda la questione del TAG abstractComponentRefs-37, che riguarda l'impiego dell'identificatore di frammento con i nomi del namespace per identificare componenti astratti.

2.7. Direzioni future per gli Identificatori

Rimangono aperte le questioni riguardanti gli identificatori sul Web.

3.1. Usare un URI per Accedere a una Risorsa

Gli agenti potrebbero usare un URI per accedere alla risorsa referenziata; questo è chiamato seguire il riferimento dell'URI. L'accesso può assumere molte forme, compresi il reperimento di una rappresentazione della risorsa (per esempio, usando GET e HEAD di HTTP), l'aggiunta o la modifica di una rappresentazione della risorsa (per esempio, usando POST o PUT di HTTP, che in alcuni casi potrebbe cambiare lo stato attuale della risorsa se le rappresentazioni sottoposte sono interpretate come istruzioni per quel fine) e la cancellazione di alcune o di tutte le rappresentazioni della risorsa (per esempio, usando DELETE di HTTP, che in alcuni casi potrebbe risultare in una cancellazione della risorsa stessa).

Potrebbe esistere più di una maniera per accedere a una risorsa per un dato URI; il contesto dell'applicazione determina quale metodo di accesso usa un agente. Per esempio, un browser potrebbe usare GET di HTTP per reperire una rappresentazione della risorsa, laddove un controllore di collegamento ipertestuale potrebbe usare HEAD di HTTP sullo stesso URI semplicemente per stabilire se è disponibile una rappresentazione. Alcuni schemi di URI pongono le aspettative circa i metodi di accesso disponibili, altri no (come lo schema URN [RFC 2141]). La sezione 1.2.2 di [URI] tratta della separazione dell'identificazione e dell'interazioni in maggior dettaglio. Per informazioni aggiuntive circa le relazioni fra metodi di accesso multipli e indirizzabilità dell'URI, si veda la conclusione del TAG "URI, Indirizzabilità e l'uso di GET e POST in HTTP".

Sebbene molti schemi di URI (§2.4) vengano associati allo stesso nome dei protocolli, ciò non implica che l'uso di tali URI sfocerà necessariamente in un accesso alla risorsa attraverso il protocollo che ha quel nome. Perfino quando un agente impiega un URI per reperire una rappresentazione, quell'accesso potrebbe avvenire attraverso gateway, proxy, cache e servizi di risoluzione dei nomi i quali sono indipendenti dal protocollo associato con il nome dello schema.

Molti schemi di URI definiscono un protocollo di interazione predefinito per tentare di accedere a una risorsa identificata. Quel protocollo di interazione è spesso la base per allocare gli identificatori entro quello schema, proprio come gli URI "http" sono definiti in termini di server HTTP basati su TCP. Comunque, ciò non implica che tutta l'interazione con tali risorse è limitata al protocollo di interazione predefinito. Ad esempio, i sistemi di reperimento dell'informaizone spesso fanno uso di proxy per interagire con una moltitudine di schemi di URI, come i proxy HTTP che vengono impiegati per accedere a risorse "ftp" e "wais". I proxy possono anche fornire servizi avanzati, come i proxy di annotazione, i quali combinano il normale reperimento dell'informazione con il reperimento aggiuntivo di metadati per fornire un visione unitaria e multidimensionale delle risorse che usano lo stesso protocollo e agenti utente come il Web non annotato. In maniera similare, potrebbero essere definiti protocolli futuri che ricomprendono i nostri sistemi attuali, usando meccanismi di interazione completamente differenti, senza cambiare gli schemi degli identificatori esistenti. Si veda anche, principio delle specifiche ortogonali (§5.1).

3.2. Tipi di rappresentazione e Tipi di Media per Internet

Una rappresentazione sono dati che codificano informazione riguardo lo stato di una risorsa. Le rappresentazioni non necessariamente descrivere la risorsa o ritraggono una parvenza della risorsa o rappresentano la risorsa in altri significati della parola "rappresentare".

Le rappresentazioni di una risorsa potrebbe essere inviata o ricevuta usando i protocolli di interazione. Questi protocolli a turno determinano la forma in cui le rappresentazioni vengono convogliate sul Web. HTTP, ad esempio, fornisce per la trasmissione delle rappresentazioni come flussi di ottetti tipizzati impiegando i tipi di media per Internet [RFC2046].

Proprio com'è importante riutilizzare schemi di URI esistenti ogni volta che sia possibile, esistono benefici significativi nell'usare flussi di media tipizzati in ottetti per le rappresentazioni perfino nel caso poco usuale in cui un nuovo schema di URI e il protocollo ad esso associato sia da definire. Ad esempio, se il tempo di Oaxaca fosse stato dirottato sul browser di Nadia impiegando un protocollo diverso da HTTP, allora il software per presentare i formati come text/xhmtl+xml e image/png sarebbe stato ancora utilizzabile se il nuovo protocollo supportasse la trasmissione di quei tipi. Questo è un esempio del principio delle specifiche ortogonali (§5.1).

Il meccanismo del tipo di media per Internet in effetti ha qualche limitazione. Per esempio, i tipi di media stringhe non supportano il tracciamento della versione (§4.2.1) o altri parametri. Si vedano le questioni del TAG uriMediaType-9 e mediaTypeManagement-45 che si occupano degli aspetti del meccanismo del tipo di media.

3.3. Inconsistenze fra Dati e Metadati della Rappresentazione

La comunicazione avvenuta con successo fra due parti dipende dalla comprensione ragionevolmente condivisa della semantica dei messaggi scambiati, sia dei dati che dei metadati. A volte, potrebbero esistere inconsistenze fra i dati e i metadati del messaggio del mittente. Esempi, osservati nella pratica, di inconsistenze fra i dati e i metadati della rappresentazione comprendono:

• L'attuale codifica di carattere di una rappresentazione (cioè, "iso-8859-1", specificata dall'attributo encoding in una dichiarazione XML) è inconsistente con il parametro dell'insieme di caratteri nei metadati della rappresentazione (cioè, "utf-8", specificata dal campo 'Content-Type' in un'intestazione HTTP).
• Il namespace (§4.5.3) dell'elemento radice dei dati della rappresentazione XML (cioè, come specificata dall'attributo "xmlns") è inconsistente con il valore del campo 'Content-Type' in un'intestazione HTTP.

D'altro canto, non esiste alcuna inconsistenza nel servire un contenuto HTML con il tipo di media "text/plain", ad esempio, poiché questa combinazione è autorizzata dalle specifiche.

Gli agenti riceventi dovrebbero scovare le inconsistenze di protocollo e compiere un adeguato recupero dell'errore.

In tal modo, ad esempio, se le parti responsabili per "weather.example.com" etichettano per errore la foto satellitare di Oaxaca come "image/gif" invece di "image/jpeg", e se il browser di Nadia rileva un prolema, il browser di Nadia non deve ignorare il problema (cioè, presentare semplicemente l'immagine JPEG) senza il consenso di Nadia. Il browser di Nadia può renderle noto il problema oppure notificarlo e compiere un'azione correttiva.

Inoltre, i fornitori di rappresentazione possono aiutare a ridurre il rischio di inconsistenze attraverso l'assegnazione attenta dei metadati della rappresentazione (in special modo quelli che si applicano a rappresentazioni che s'incrociano). La sezione sui tipi di media per XML (§4.5.7) presenta un esempio di riduzione del rischio di errore fornendo nessun metadato riguardo alla codifica di carattere quando si serve dell'XML.

L'accuratezza dei metadati poggia sugli amministratori di server, gli autori delle rappresentazioni e il software che utilizzano. in pratica, le capacità degli strumenti e le relazioni sociali potrebbero essere i fattori limitanti.

L'accuratezza di questi e altri campi di metadati è importante per le dinamiche risorse Web, dove un pochino di ragionamento e programmazione può spesso assicurare metadati corretti per un vasto numero di risorse.

Spesso esiste una separazione del controllo fra gli utenti che creano le risorse delle rappresentazioni e i gestori dei server che manutengono il software del sito Web. Dato che in genere è il software del sito Web che fornisce i metadati associati ad una risorsa, ne consegue che è richiesta la coordinazione fra i gestori dei server e i creatori di contenuto.

In particolare, i creatori di contenuto necessitano di essere in grado di controllare il tipo di contenuto (per estensibilità) e la codifica di carattere (per un'adeguata internazionalizzazione).

La conclusione del TAG "Metadati autoritativi" spiega in maggior dettaglio come trattare l'inconsistenza dati/metadati e come può essere usata la configurazione del server per evitarla.

3.4. Interazioni sicure

Il reperimento di Nadia dell'informazione meteo (un esempio di un'interrogazione di sola lettura o di ricerca) si qualifica come una interazione "sicura"; una interazione sicura è quella in cui l'agente non impone alcun obbligo al di là dell'interazione. Un agente potrebbe imporre un obbligo attraverso altri mezzi (come con la firma di un contratto). Se un agente non contrae un obbligo prima di un'interazione sicura, non deve contrarla in seguito.

Altre interazioni Web assomigliano ad ordini più che a interrogazioni. Queste interazioni insicure potrebbero causare una modifica nello stato di una risorsa e l'utente potrebbe essere ritenuto responsabile per le conseguenze di queste interazioni. Le interazioni non sicure includono sottoscrivere una newsletter, scrivere ad una lista o modificare un database. Nota: In questo contesto, la parola "insicura" non significa necessariamente "pericolosa"; il termine "sicuro" è usato nella sezione 9.1.1 della [RFC2616] e "insicuro" è il naturale contrario.

Le interazioni sicure sono importanti perché queste sono interazioni dove gli utenti possono navigare tranquilli e dove gli agenti (compresi i motori di ricerca e i browser che pre-immagazzinano i dati per l'utente) possono seguire i collegamenti ipertestuali in modo sicuro. Gli utenti (o gli agenti che agiscono in loro vece) non si impegnano a far nulla se non a interrogare una risorsa o a seguire un collegamento ipertestuale.

Per esempio, è scorretto pubblicare un URI che, quando viene seguito come parte di un collegamento ipertestuale, iscrive un utente ad una mailing list. Si ricordi che i motori di ricerca potrebbero seguire tali collegamenti ipertestuali.

Il fatto che il GET HTTP, il metodo d'accesso più di frequente utilizzato quando si segue un collegamento ipertestuale, è sicuro non implica che tutte le interazioni sicure debbano essere fatte attraverso il GET di HTTP. A volte, potrebbero esistere buone ragioni (come requisiti di riservatezza o limiti pratici sulla lunghezza dell'URI) a condurre un'operzione altrimenti sicura a usare un meccanismo in genere riservata a operazioni insicure (cioè, il POST di HTTP).

Per maggiori informazioni riguardo le operazioni sicure e insicure nell'usare GET e POST di HTTP e nel trattare aspetti di sicurezza intorno all'uso di GET di HTTP, si veda la conclusione del TAG "URI, Indirizzabilità e l'uso di GET e POST in HTTP".

3.5. Gestione della Rappresentazione

Un proprietario di URI potrebbe mettere a disposizione zero o più rappresentazioni autoritative della risorsa identificata da quell'URI. Esiste un beneficio per la comunità nel fornire le rappresentazioni.

Ad esempio, i proprietari degli URI del namespace XML dovrebbero usarli per identificare un documento del namespace (§4.5.4).

Solo perché le rappresentazioni sono disponibili non significa che è sempre desiderabile recuperarle. Infatti, in alcuni casi è vero il contrario.

Seguire un riferimento URI ha un costo (potenzialmente significativo) nelle risorse di calcolo e della larghezza di banda, potrebbe avere implicazioni di sicurezza e potrebbe imporre una latenza significativa all'applicazione che segue il riferimento. Tranne quando necessario, si dovrebbe evitare di seguire il riferimento dell'URI.

Le sezioni seguenti discutono alcuni aspetti della gestione della rappresentazione, compresi promuovere la persistenza dell'URI (§3.5.1), gestire l'accesso alle risorse (§3.5.2) e supportare la navigazione (§3.5.3).

3.6. Direzioni future per l'Interazione

Rimangono questioni aperte riguardanti le interazioni sul Web. Il TAG si aspetta versioni future di questo documento per indirizzare in maggior dettaglio la relazione fra l'architetuuta ivi descritta, Web Services {Servizi Web}, sistemi peer-to-peer, sistemi di messaggistica istantanea (come [RFC3920]), flussi audio (come RTSP [RFC2326]), e il voice-over-IP {voce-su-IP} (come SIP [RFC3261]).

4.1. Formati di Dati Binari e Testuali

I formati di dati binari sono quelli in cui porzioni dei dati sono codificati per l'uso diretto da parte dei processori di computer, ad esempio little-endian 32 bit e IEEE 64 bit a virgola mobile a precisione doppia. Le porzioni di dati così rappresentate comprendono valori numerici, puntatori e dati compressi di ogni sorta.

Un formato di dati testuali è uno in cui i dati sono specificati in una codifica definita come una sequenza di caratteri. HTML, la posta elettronica Internet e tutti i formati basati su XML (§4.5) sono testuali. Sempre di più, i formati di dati testuali internazionalizzati si riferiscono al repertorio Unicode [UNICODE] per le definizioni dei caratteri.

Se un formato di dati è testuale, come definito in questa sezione, ciò non implica che dovrebbe essere servito con un tipo di media iniziante con "text/". Sebbene i formati basati su XML sono testuali, molti formati basati su XML non consistono principalmente di elocuzioni nel linguaggio naturale. Si veda la sezione sui tipi di media per XML (§4.5.7) per le questioni che sorgono quando viene usato "text/" in congiunzione con un formato basato su XML.

In principio, tutti i dati sono rappresentati utilizzando formati testuali. In pratica, alcuni tipi di contenuto (ovvero, quelli audio e video) sono rappresentati in genere usando formati binari.

Le negoziazioni tra i formati di dati binari e testuali sono complesse e dipendente dall'applicazione. I formati binari possono essere significativamente più compatti, in particolare per complesse strutture di dati ricche di puntatori. Inoltre, essi possono essere consumati più rapidamente dagli agenti in quei casi in cui vengono caricati in memoria e utilizzati senza nessuna o con minima conversione. Si noti, comunque, che tali casi sono relativamente inusuali in quanto l'uso diretto potrebbe aprire la porta a questioni di sicurezza alle quali ci si può indirizzare solo in maniera pratica esaminando in dettaglio ogni aspetto della struttura di dati.

I formati testuali sono di solito più portabili e interoperabili. I formati testuali inoltre hanno il considerevole vantaggio che possono essere letti direttamente dagli esseri umani (e compresi, data una sufficiente documentazione). Questo può semplificare i compiti nel creare e manutenere il software e permettere l'intervento diretto di umani nella catena dell'elaborazione senza il ricorso a strumenti più complessi di un onnipresente editor testuale. Infine, esso semplifica il compito necessariamente umano di imparare i nuovi formati di dati; questo è ciò che viene chiamato l'effetto "vista codice".

È importante enfatizzare che l'intuizione in merito a problemi che riguardano la dimensione dei dati e la velocità di elaborazione non è una guida affidabile nella progettazione del formato; studi quantitativi sono essenziali per una corretta comprensione delle negoziazioni. Perciò, i progettisti della specifica di un formato di dati dovrebbero fare una scelta ponderata fra il progetto di un formato binario e testuale.

Si veda la questione del TAG binaryXML-30.

4.2. Tracciamento della Versione ed Estensibilità

In un mondo perfetto, i progettisti di linguaggio inventerebbero linguaggi che incontrano alla perfezione i requisiti che sono stati presentati loro, i requisiti sarebbero un modello perfetto del mondo, non cambierebbero mai nel tempo e tutte le implementazioni sarebbero perfettamente interoperabili perché le specifiche non avrebbero alcuna variabilità.

Nel mondo reale, i progettisti di linguaggio non s'indirizzano alla perfezione ai requisiti dacché li interpretano, i requisiti danno un modello non accurato del mondo, vengono presentati requisiti in conflitto fra loro e che cambiano nel tempo. Come risultato, i progettisti negoziano con gli utenti, fanno compromessi e spesso introducono meccanismi di estensibilità in modo tale che sia possibile lavorare intorno ai problemi a breve termine. Sul lungo termine, producono molteplici versioni dei loro linguaggi, poiché il problema, e la loro comprensione di esso, evolvono. La variabilità che ne consegue nelle specifiche, nei linguaggi e nelle implementazioni introduce dei costi di interoperabilità.

L'estensibilità e il tracciamento della versione sono strategie per aiutare a gestire l'evoluzione naturale dell'informazione sul Web e le tecnologie usate per rappresentare quell'informazione. Per maggiori chiarimenti sul come queste strategie introducano la variabilità e sul come la variabilità impatti sull'interoperabilità, si veda la Variabilità nelle Specifiche.

Si veda la questione del TAG XMLVersioning-41, che riguarda le buone prassi nella progettazione di linguaggi XML estensibili e per trattare il tracciamento della versione. Si veda inoltre "Web Architecture: Extensible Languages" [EXTLANG].

4.3. Separazione di Contenuto, Presentazione e Interazione

Il Web è un ambiente eterogeneo dove una vasta gamma di agenti forniscono accesso al contenuto per gli utenti con una vasta gamma di capacità. È buona prassi per gli autori creare contenuti che possono il più vasto pubblico possibile, compresi gli utenti di computer con desktop grafico, dispositivi palmari e telefoni cellulari, utenti con disabilità i quali potrebbero richiedere sintetizzatori vocali e dispositivi non ancora immaginati. Inoltre, gli autori non possono predire in alcuni casi come un agente mostrerà o elaborerà i loro contenuti. L'esperienza mostra che la separazione del contenuto, della presentazione e dell'interazione promuove il riutilizzo e l'indipendenza dal dispositivo del contenuto; ciò consegue dal principio delle specifiche ortogonali (§5.1).

Questa separazione facilita anche il riutilizzo di contenuto originario scritto per molteplici contesti distributivi. A volte, esperienze funzionali per l'utente pensate per qualsiasi contesto distributivo possono generarsi con l'uso di un processo di adattamento applicato ad una rappresentazione che non dipende dal meccanismo d'accesso. Per maggiori informazioni sui principi d'indipendenza dal dispositivo, si veda [DIPRINCIPLES].

Si noti che quando contenuto, presentazione e interazione sono seprati dalla progettazione, gli agenti hanno bisogno di ricombinarli. Esiste uno spettro di ricombinazione, con "client tuttofare" ad un capo e "server tuttofare" dall'altro.

Esistono vantaggi per ciascun approccio. Per esempio quando un client (come un telefono cellulare) comunica le capacità del dispositivo al server (ad esempio, usando CC/PP), il server può confezionare il contenuto recapitato per adattarsi a quel client. Il server può, ad esempio, abilitare scaricamenti più veloci aggiustando i collegamenti per riferirsi a immagini con minore risoluzione, a video più piccoli o a nessun video del tutto. In modo simile, se il contenuto è stato scritto in molteplici rami, il server può rimuovere i rami inutilizzati prima della consegna. In aggiunta, confezionando il contenuto per incontrare le caratteristiche di un client di riferimento, il server può aiutare a ridurre l'elaborazione dal lato client. In ogni caso, rendere il contenuto specifico in questa maniera riduce l'efficienza del servizio di cache.

D'altro canto, anche progettare contenuto che può essere ricombinato dal client tende a far sì che il contenuto sia applicabile ad una vasta gamma di dispositivi. Questa progettazione inoltre facilità l'efficienza del servizio di cache e offre agli utenti più alternative di presentazione. Si possono utilizzare i fogli di stile dipendenti dal dispositivo per confezionare il contenuto dal lato client per particolari gruppi di dispositivi di riferimento. Per contenuti testuali con una struttura regolare e ripetitiva, la dimensione combinata del contenuto di testo più il foglio di stile è tipicamente minore del contenuto completamente ricombinato; i risparmi incrementano ulteriormente se il foglio di stile viene riutilizzato da altre pagine.

In pratica viene usata spesso una combinazione di entrambi gli approcci. La decisione di progetto sul dove dovrebbe posizionarsi un'applicazione in questo spettro dipende dalla potenza del client, dalla potenza e dal carico del server e dalla larghezza di banda del medium che li connette. Se il numero di client possibili è illimitato, l'applicazione scalerà meglio se un'elaborazione maggiore viene delegata al client.

Naturalmente, potrebbe non essere desiderabile raggiungere il pubblico più vasto. I progettisti dovrebbero considerare tecnologie appropriate per limitare il pubblico, come la crittografia e il controllo d'accesso (§3.5.2).

Alcuni formati di dati sono progettati per descrivere la presentazione (inclusi SVG e XSL Formatting Objects {Oggetti Strutturanti}). I formati di dati come questi dimostrano che fin qui si può solo separare il contenuto dalla presentazione (o dall'interazione); ad un certo punto diviene necessario parlare della presentazione. Per il principio delle specifiche ortogonali (§5.1) questi formati di dati dovrebbero solo indirizzare a questioni di presentazione.

Si vedano le questioni del TAG formattingProperties-19 (concernenti l'interoperabilità nel caso di proprietà e nomi di struttura) e contentPresentation-26 (concernente la separazione della marcatura semantica e di presentazione).

4.4. Ipertesto

Una caratteristica che definisce il Web è che consente i riferimenti integrati ad altre risorse attraverso gli URI. La semplicità di creare collegamenti ipertestuali usando i riferimenti con URI assoluti (<a href="http://www.example.com/foo">) e URI relativi (<a href="foo"> and <a href="foo#anchor">) è responsabile in parte (forse in larga parte) del successo del Web ipertestuale come lo conosciamo oggi.

Quando una rappresentazione di una singola risorsa contiene un riferimento ad un'altra risorsa, espressa con un URI che identifica quell'altra risorsa, questo costituisce un collegamento fra le due risorse. Anche metadati aggiuntivi potrebbere formare parte del collegamento (si veda [XLink10], ad esempio). Nota: In questo documento, il termine "collegamento" in genere significa "relazione", non "connessione fisica".

I formati che permettono l'utilizzo degli URI agli autori di contenuto al posto degli identificatori locali promuovo l'effetto di rete: il valore di questi formati cresce con la dimensione del Web impiegato.

Ciò che fanno gli agenti con un collegamento ipertestuale non è vincolato dall'architettura Web e potrebbe dipendere dal contesto applicativo. Gli utenti dei collegamenti iperetestuali si aspettano di essere in grado di naviagre fea le rappresentazioni seguendo i collegamenti.

I formati di dati che non consentono agli autori di contenuto di creare collegamenti ipertestuali conducono alla creazione di "nodi terminali" sul Web.

4.5. Formati di Dati basati su XML

Molti formati di dati sono basati su XML, che equivale a dire che essi si conformano alle regole di sintassi definite nella specifica XML [XML10] o [XML11]. Questa sezione tratta questioni che sono specifiche di tali formati. Chiunque cerchi una guida in questo campo si affretti a consultare le "Linee Guida Per l'Utilizzo di XML nei Protocolli IETF" [IETFXML], che contiene una discussione approfondita sulle considerazioni che decidono se XML debba essere utilizzato o no, come pure le linee guida specifiche sul come debba essere utilizzato. Anche se è diretta alle applicazioni Internet con specifico riferimento ai protocolli, la discussione è applicabile in genere anche agli scenari Web.

La discussione qui dovrebbe essere vista come sussidiaria al contenuto di [IETFXML]. Si prenda a riferimento anche "Linee Guida per l'Accessibilità in XML" [XAG] per un aiuto nella progettazioni di formati XML che abbassino le barriere per l'accessibilità sul Web a favore delle persone con disabilità.

4.6. Direzioni Future per i Formati di Dati

I formati di dati abilitano la creazione di nuove applicazioni per fare uso dell'infrastruttura dello spazio informativo. Il Web Semantico è una di tali applicazioni, costruita in cima alla RDF [RDFXML]. Questo documento non discute del Web Semantico in dettaglio; il TAG si aspetta che i volumi futuri di questo documento lo faranno. Si veda la relativa questione del TAG httpRange-14.

5.1. Specifiche Ortogonali

L'identificazione, l'interazione e la rappresentazione sono concetti ortogonali, il che significa che le tecnologie utilizzate per l'identificazione, l'interazione e la rappresentazione potrebbero evolvere in maniera indipendente. Per esempio:

• Le risorse sono identificate con gli URI. Gli URI possono essere pubblicati senza costruire alcuna rappresentazione della risorsa o senza determinare se sia disponibile una qualsiasi rappresentazione.
• Una sintassi generica di permette agli agenti di funzionare in molti casi senza conoscere le specifiche degli schemi di URI.
• In molti casi si potrebbe modificare la rappresentazione di una risorsa senza intralciare i riferimenti esistenti alla risorsa (ad esempio, usando la negoziazione del contenuto).

Quando due specifiche sono ortogonali, si potrebbe cambiarne una senza richiedere modifiche all'altra, perfino se una avesse delle dipendenze con l'altra. Ad esempio, sebbene la specifica HTTP dipenda dalla specifica URI, le due strade evolvono in maniera indipendente. Questa ortogonalità incrementa la flessibilità e la robustezza del Web. Ad esempio, ci si potrebbe riferire con un URI ad un'immagine senza conoscere nulla riguardo al formato scelto per rappresentare l'immagine. Questo ha facilitato l'introduzione dei formati di immagine come PNG e SVG senza interrompere i riferimenti esistenti alle risorse dell'immagine.

L'esperienza dimostra che sorgono problemi dove i concetti ortogonali occorrono in una singola specifica. Si consideri, ad esempio, la specifica HTML la quale include la specifica ortogonale x-www-form-urlencoded. Gli sviluppatori software (ad esempio, delle applicazioni [CGI]) potrebbero trovare in minor tempo la specifica se essa fosse pubblicata separatamente e poi citata dalle specifiche HTTP, URI e HTML.

Sorgono problemi anche quando le specifiche tentano di modificare le astrazioni ortogonali descritte altrove. Una versione storica della specifica HTML aggiunse un valore "Refresh" all'attributo http-equiv dell'elemento meta. Fu definito essere equivalente all'intestazione HTTP con lo stesso nome. Gli autori della specifica HTTP ultimamente hanno deciso di non fornire questa intestazione e ciò ha messo in modo imbarazzante le due specifiche in disaccordo l'una con l'altra. Il Gruppo di Lavoro del W3C alla fine ha rimosso il valore "Refresh".

Una specifica dovrebbe indicare chiaramente quali caratteristiche si sovrappongono a quelle governate da un'altra specifica.

5.2. Estensibilità

L'informazione nel Web e le tecnologie usate per rappresentare quell'informazione cambiano nel tempo. L'estensibilità è la proprietà di una tecnologia che promuove l'evoluzione senza sacrificare l'interoperabilità. Alcuni esempi di tecnologie di successo progettate per consentire la modifica minimizzando al contempo l'interruzione includono:

• il fatto che gli schemi di URI sono specificati in modo ortogonale;
• l'utilizzo di un insieme aperto dei tipi di media per Internet nella posta e in HTTP per specificare l'interpretazione del documento;
• la separazione della grammatica generica XML e l'insieme aperto dei namespace XML per i nomi di elemento e attributo;
• i modelli di estensibilitàextensibility nei Fogli di Stile a Cascata {Cascading Style Sheets} (CSS), XSLT 1.0 e SOAP;
• gli agenti utenti di tipo plug-in.

Un esempio di meccanismo estensivo non di successo sono le estensioni obbligatorie di HTTP [HTTPEXT]. La comunità ha cercato meccanismi per estendere HTTP, ma in apparenza i costi della proposta dell'estensione obbligatoria (notevole per complessità) ha sopravanzato i benefici e in tal modo ne ha impedito l'adozione..

Di seguito discutiamo la proprietà dell'"estensibilità", esposta dagli URI, da alcuni formati di dati e da alcuni protocolli (attraverso l'incorporazione di nuovi messaggi).

Linguaggio di sottoinsieme: un linguaggio è un sottoinsieme (o "profilo") di un secondo linguaggio se ogni documento nel primo linguaggio è un documento valido anche nel secondo linguaggio e ha la stessa interpretazione nel secondo linguaggio.

Linguaggio esteso: se un linguaggio è un sottoinsieme di un altro, quest'ultimo soprainsieme è chiamato un linguaggio esteso; la differenza tra i linguaggio è chiamata l'estensione. Chiaramente, estendere un linguaggio per l'interoperabilità è meglio che creare un linguaggio incompatibile.

Idealmente, molte istanze di un linguaggio di soprainsieme possono essere elaborate in maniera sicura e proficua come se queste esistano nel linguaggio di sottoinsieme. I linguaggi che possono evolvere in questa maniera, permettendo alle applicazioni di fornire nuova informazione quando necessario pur continuando a interoperare con le applicazioni che capiscono solo un sottoinsieme del linguaggio in uso, si dice che sono "estensibili". I progettisti di linguaggio possono facilitare l'estensibilità definendo il comportamento predefinito delle estensioni sconosciute — ad esempio, che esse siano ignorate (in qualche modo predefinito) o dovrebbero essere considerate errori.

Ad esempio, nel Web fin dal principio, gli agenti HTML seguivano la convenzione di ignorare i tag sconosciuti. Questa scelta lasciava spazio all'innovazione (cioè, elementi non standard) e incoraggiava l'impiego di HTML. In ogni caso, sorsero anche problemi di interoperabilità. In questo tipo di ambiente, esiste un'inevitabile tensione fra l'interoperabilità nel breve periodo e il desiderio di estensibilità. L'esperienza ci mostra che le progettazioni che raggiungono il giusto bilanciamento fra permettere il cambiamento e preservare l'interoperabilità tendono di più a far prosperare e meno ad intralciare la comunità Web. Le specifiche ortogonali (§5.1) aiutano a ridurre il rischio di intralcio.

Per una discussione ulteriore, si veda la sezione sul tracciamento della versione e l'estensibilità (§4.2). Si veda anche la questione del TAG xmlProfiles-29 e HTML Dialects.

5.3. Gestione dell'errore

Nei sistemi informativi di rete gli errori si verificano. Una condizione di errore può essere ben caratterizzata (cioè, gli errori di non corretta formazione oppure gli errori del client 4xx in HTTP) o sorgere in maniera inopinata. La correzione dell'errore significa che un agente ripara una condizione in modo tale che all'interno del sistema, è come se l'errore non si fosse mai verificato. Un esempio di correzione d'errore coinvolge la ritrasmissione dei dati in risposta ad una caduta temporanea della rete. Il recupero dell'errore significa che un agente non ripara una condizione d'errore, ma continua ad elaborare puntando sul fatto che si è verificato l'errore.

Gli agenti correggono di frequente gli errori senza che l'utente ne sia conscio, risparmiando agli utenti i dettagli delle complesse comunicazioni di rete. D'altro, è importante che gli agenti recuperino l'errore in un modo che sia evidente per gli utenti, dal momento che gli agenti si stanno comportando come se fossero gli utenti.

A un agente non viene richiesto di interrompere l'utente (cioè, facendo uscir fuori una finestra di conferma) per ottenere il consenso. L'utente potrebbe acconsentire attraverso le opzioni pre-selezionate di configurazione, modi oppure interruttori selezionabili dell'interfaccia utente, con un'opera di rapporto appropriata all'utente quando l'agente scova un errore. Gli sviluppatori di agenti non dovrebbero ignorare le questioni di usabilità quando progettano il comportamento per il recupero dell'errore.

Per promuovere l'interoperabilità, i progettisti di specifica dovrebbero identificare le condizioni prevedibili di errore. L'esperienza ha portato a formulare le seguenti osservazioni sugli approcci alla gestione dell'errore.

• I progettisti di protocollo dovrebbero fornire sufficiente informazione sulla condizione d'errore in modo tale che un agente possa localizzare la condizione dell'errore. Per esempio, un codice di status 404 di HTTP (non trovato) è utile perché consente agli agenti utente di presentare la relativa informazione agli utenti, abilitandoli a contattare il fornitore della rappresentazione in caso di problemi.
• L'esperienza con il costo della costruzione di un agente utente nel trattare con diverse forme di contenuti HTML malformati ha convinto i progettisti della specifica XML a richiedere che gli agenti falliscano nel momento in cui incontrino contenuto malformato. Poiché gli utenti tendono a non tollerare tali fallimenti, questa scelta ha messo pressione su tutte le parti a rispettare i vincoli di XML, per il beneficio di tutti.
• Un agente che incontra del contenuto non riconosciuto potrebbe trattarlo in un certo numero di modi, incluso considerarlo un errore; si veda anche la sezione sulla estensibilità e il tracciamento della versione (§4.2).
• Il comportamento dell'errore che è appropriato per una persona potrebbe non esserlo per un software. Le persone sono in grado di esercitare un giudizio in modi che sono in genere preclusi agli applicativi. Una risposta informale d'errore potrebbe esser sufficiente per una persona, ma non per un elaboratore.

Si veda la questione del TAG contentTypeOverride-24, che concerne la fonte dei metadati autoritativi.

5.4. Interoperabilità basata sul protocollo

Il Web segue la tradizione Internet per cui le sue interfacce importanti sono definite in termini di protocolli, specificando la sintassi, la semantica e i conseguenti vincoli dei messaggi scambiati. I protocolli progettati per essere elastici di fronte ad ambienti che variano in maniera ampia hanno aiutato il Web a scalare e ha facilitato la comunicazione attraverso connessioni multiple affidabili. Le tradizionali interfacce di programmazione d'applicativo {application programming interfaces} (le API) non sempre prendono in considerazione questi vincoli, né dovrebbero essere richiesto loro. Un effetto della progettazione basata sul protocollo è che la tecnologia condivisa fra gli agenti spesso dura più a lungo degli agenti stessi.

È cosa comune per i programmatori lavorare con il Web per scrivere codice che genera e interpreta questi messaggi in mdoo diretto. È meno comune, ma non inusuale, per gli utenti finali avere un'esposizione diretta di quei messaggi. Spesso è preferibile fornire agli utenti l'accesso ai dettagli del formato e del protocollo: permettendo loro di "vedere la fonte", con questo mezzo essi possono fare esperienza sulle lavorazioni del sistema sottostante.

7. Riferimenti

CGI

Common Gateway Interface/1.1 Specification. Available at http://hoohoo.ncsa.uiuc.edu/cgi/interface.html.

CHIPS

Common HTTP Implementation Problems, O. Théreaux, January 2003. This W3C Team Submission is available at http://www.w3.org/TR/chips/.

CUAP

Common User Agent Problems, K. Dubost, January 2003. This W3C Team Submission is available at http://www.w3.org/TR/cuap.

Cool

Cool URIs don't change T. Berners-Lee, W3C, 1998 Available at http://www.w3.org/Provider/Style/URI. Note that the title is somewhat misleading. It is not the URIs that change, it is what they identify.

Eng90

Knowledge-Domain Interoperability and an Open Hyperdocument System, D. C. Engelbart, June 1990.

HTTPEXT

Mandatory Extensions in HTTP, H. Frystyk Nielsen, P. Leach, S. Lawrence, 20 January 1998. This expired Internet Draft is available at http://www.w3.org/Protocols/HTTP/ietf-http-ext/draft-frystyk-http-mandatory.

IANASchemes

IANA's online registry of URI Schemes is available at http://www.iana.org/assignments/uri-schemes.

IETFXML

IETF Guidelines For The Use of XML in IETF Protocols, S. Hollenbeck, M. Rose, L. Masinter, eds., 2 November 2002. This Internet Draft is available at http://www.imc.org/ietf-xml-use/xml-guidelines-07.txt. If this document is no longer available, refer to the ietf-xml-use mailing list.

INFOSET

XML Information Set (Second Edition), R. Tobin, J. Cowan, Editors, W3C Recommendation, 04 February 2004, http://www.w3.org/TR/2004/REC-xml-infoset-20040204. Latest version available at http://www.w3.org/TR/xml-infoset.

IRI

IETF Internationalized Resource Identifiers (IRIs), M. Dürst, M. Suignard, Eds., November 2004. In an 8 December 2004 announcement, the IESG approved draft-duerst-iri-11 as a Proposed Standard of the IETF. References to the IRI specification in Volume One of Architecture of the World Wide Web are to that Proposed Standard. Once the IETF issues a Request For Comments (RFC) number for the specification, this W3C Recommendation may be updated to refer to that RFC. See also the latest information about the IRI specification.

MEDIATYPEREG

IANA's online registry of Internet Media Types is available at http://www.iana.org/assignments/media-types/index.html.

OWL10

OWL Web Ontology Language Reference, M. Dean, G. Schreiber, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-ref-20040210/. Latest version available at http://www.w3.org/TR/owl-ref/.

P3P10

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification, M. Marchiori, Editor, W3C Recommendation, 16 April 2002, http://www.w3.org/TR/2002/REC-P3P-20020416/. Latest version available at http://www.w3.org/TR/P3P/.

RDDL

Resource Directory Description Language (RDDL), J. Borden, T. Bray, eds., 1 June 2003. This document is available at http://www.tbray.org/tag/rddl/rddl3.html.

RDFXML

RDF/XML Syntax Specification (Revised), D. Beckett, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/. Latest version available at http://www.w3.org/TR/rdf-syntax-grammar.

RELAXNG

The RELAX NG schema language project.

REST

Representational State Transfer (REST), Chapter 5 of "Architectural Styles and the Design of Network-based Software Architectures", Doctoral Thesis of R. T. Fielding, 2000. Designers of protocol specifications in particular should invest time in understanding the REST model and the relevance of its principles to a given design. These principles include statelessness, clear assignment of roles to parties, uniform address space, and a limited, uniform set of verbs. Available at http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm.

RFC2045

IETF RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, N. Freed, N. Borenstein, November 1996. Available at http://www.ietf.org/rfc/rfc2045.txt.

RFC2046

IETF RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, N. Freed, N. Borenstein, November 1996. Available at http://www.ietf.org/rfc/rfc2046.txt.

RFC2119

IETF RFC 2119: Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt.

RFC2141

IETF RFC 2141: URN Syntax, R. Moats, May 1997. Available at http://www.ietf.org/rfc/rfc2141.txt.

RFC2326

IETF RFC 2326: Real Time Streaming Protocol (RTSP), H. Schulzrinne, A. Rao, R. Lanphier, April 1998. Available at: http://www.ietf.org/rfc/rfc2326.txt.

RFC2397

IETF RFC 2397: The “data” URL scheme, L. Masinter, August 1998. Available at: http://www.ietf.org/rfc/rfc2397.txt.

RFC2616

IETF RFC 2616: Hypertext Transfer Protocol - HTTP/1.1, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999. Available at http://www.ietf.org/rfc/rfc2616.txt.

RFC2717

IETF Registration Procedures for URL Scheme Names, R. Petke, I. King, November 1999. Available at http://www.ietf.org/rfc/rfc2717.txt.

RFC2718

IETF RFC 2718: Guidelines for new URL Schemes, L. Masinter, H. Alvestrand, D. Zigmond, R. Petke, November 1999. Available at: http://www.ietf.org/rfc/rfc2718.txt.

RFC2818

IETF RFC 2818: HTTP Over TLS, E. Rescorla, May 2000. Available at: http://www.ietf.org/rfc/rfc2818.txt.

RFC3023

IETF RFC 3023: XML Media Types, M. Murata, S. St. Laurent, D. Kohn, January 2001. Available at: http://www.ietf.org/rfc/rfc3023.txt

RFC3236

IETF RFC 3236: The 'application/xhtml+xml' Media Type, M. Baker, P. Stark, January 2002. Available at: http://www.ietf.org/rfc/rfc3236.txt

RFC3261

IETF RFC 3261: SIP: Session Initiation Protocol, J. Rosenberg, H. Schulzrinne, G. Camarillo, et. al., June 2002. Available at: http://www.ietf.org/rfc/rfc3261.txt

RFC3920

IETF RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core, P. Saint-Andre, Ed., October 2004. Available at: http://www.ietf.org/rfc/rfc3920.txt

RFC977

IETF RFC 977: Network News Transfer Protocol, B. Kantor, P. Lapsley, February 1986. Available at http://www.ietf.org/rfc/rfc977.txt.

SOAP12

SOAP Version 1.2 Part 1: Messaging Framework, J. Moreau, N. Mendelsohn, H. Frystyk Nielsen, et. al., Editors, W3C Recommendation, 24 June 2003, http://www.w3.org/TR/2003/REC-soap12-part1-20030624/. Latest version available at http://www.w3.org/TR/soap12-part1/.

SVG11

Scalable Vector Graphics (SVG) 1.1 Specification, 藤沢 淳, J. Ferraiolo, D. Jackson, Editors, W3C Recommendation, 14 January 2003, http://www.w3.org/TR/2003/REC-SVG11-20030114/. Latest version available at http://www.w3.org/TR/SVG11/.

UNICODE

The Unicode Consortium, The Unicode Standard, Version 4, ISBN 0-321-18578-1, as updated from time to time by the publication of new versions. See http://www.unicode.org/unicode/standard/versions for the latest Unicode version and additional information on versions of the standard and of the Unicode Character Database.

URI

IETF Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter, Eds., September 2004. In an 18 October 2004 announcement, the IESG approved draft-fielding-uri-rfc2396bis-07 as a Full Standard of the IETF. References to the URI specification in Volume One of Architecture of the World Wide Web are to that Full Standard. Once the IETF issues a Request For Comments (RFC) number for the specification, this W3C Recommendation may be updated to refer to that RFC. See also the latest information about the URI specification.

UniqueDNS

IAB Technical Comment on the Unique DNS Root, B. Carpenter, 27 September 1999. Available at http://www.icann.org/correspondence/iab-tech-comment-27sept99.htm.

VOICEXML2

Voice Extensible Markup Language (VoiceXML) Version 2.0, B. Porter, A. Hunt, K. Rehor, et. al., Editors, W3C Recommendation, 16 March 2004, http://www.w3.org/TR/2004/REC-voicexml20-20040316/. Latest version available at http://www.w3.org/TR/voicexml20.

XHTML11

XHTML™ 1.1 - Module-based XHTML, S. McCarron, M. Altheim, Editors, W3C Recommendation, 31 May 2001, http://www.w3.org/TR/2001/REC-xhtml11-20010531. Latest version available at http://www.w3.org/TR/xhtml11/.

XLink10

XML Linking Language (XLink) Version 1.0, E. Maler, S. DeRose, D. Orchard, Editors, W3C Recommendation, 27 June 2001, http://www.w3.org/TR/2001/REC-xlink-20010627/. Latest version available at http://www.w3.org/TR/xlink/.

XML-ID

xml:id Version 1.0, D. Veillard, J. Marsh, Editors, W3C Working Draft (work in progress), 07 April 2004, http://www.w3.org/TR/2004/WD-xml-id-20040407. Latest version available at http://www.w3.org/TR/xml-id/.

XML10

Extensible Markup Language (XML) 1.0 (Third Edition), F. Yergeau, J. Paoli, C. M. Sperberg-McQueen, et. al., Editors, W3C Recommendation, 04 February 2004, http://www.w3.org/TR/2004/REC-xml-20040204. Latest version available at http://www.w3.org/TR/REC-xml.

XML11

Extensible Markup Language (XML) 1.1, J. Paoli, C. M. Sperberg-McQueen, J. Cowan, et. al., Editors, W3C Recommendation, 04 February 2004, http://www.w3.org/TR/2004/REC-xml11-20040204/. Latest version available at http://www.w3.org/TR/xml11/.

XMLNS

Namespaces in XML 1.1, R. Tobin, D. Hollander, A. Layman, et. al., Editors, W3C Recommendation, 04 February 2004, http://www.w3.org/TR/2004/REC-xml-names11-20040204. Latest version available at http://www.w3.org/TR/xml-names11/.

XMLSCHEMA

XML Schema Part 1: Structures, D. Beech, M. Maloney, H. S. Thompson, et. al., Editors, W3C Recommendation, 02 May 2001, http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/. Latest version available at http://www.w3.org/TR/xmlschema-1/.

XPTRFR

XPointer Framework, E. Maler, N. Walsh, P. Grosso, et. al., Editors, W3C Recommendation, 25 March 2003, http://www.w3.org/TR/2003/REC-xptr-framework-20030325/. Latest version available at http://www.w3.org/TR/xptr-framework/.

XSLT10

XSL Transformations (XSLT) Version 1.0, J. Clark, Editor, W3C Recommendation, 16 November 1999, http://www.w3.org/TR/1999/REC-xslt-19991116. Latest version available at http://www.w3.org/TR/xslt.