3. Wireless Markup Language
[WML] è un linguaggio markup conforme allo standard [XML], ottimizzato per terminali portatili ma basato sulla stessa filosofia di HTML: separazione tra contenuto e presentazione, struttura ipertestuale.
3.1. Differenze con HTML
Alcune differenze interessanti rispetto ad HTML sono:
- è conforme alle specifiche
[WML] quindi, ad esempio, tutti i
tag devono essere chiusi (ad ogni
<tag>deve seguire un corrispondente</tag>) e quelli che sono vuoti per definizione devono avere forma<tag/>. XML è case-sensitive e quindi tutti i tag devono stare obbligatoriamente nella forma minuscola. Inoltre il valore di ogni attributo deve essere racchiuso tra virgolette singole o doppie. - ogni singolo file WML può contenere molte card (l'equivalente di una schermata) organizzate tra loro in forma ipertestuale. In questo modo è possibile aumentare l'efficienza della trasmissione ottenendo, con una sola richiesta, una sequenza di pagine tra loro correlate.
- è previsto che il browser tenga in memoria un environment in forma di valori associati a variabili. Ogni file WML può settare nuove variabili nell'environment, cancellare quelle esistenti oppure utilizzare, con un metodo a sostituzione, le variabili lasciate in eredità dai file precedenti. Questo meccanismo può essere usato per simulare i cookie.
- è previsto un meccanismo ad eventi che scatenano azioni, anche, ad esempio, in seguito allo scadere di timer.
- tutti i tag hanno 2 attributi opzionali: un identificatore univoco
ided una classeclass.
3.2. Il preambolo
Tutti i testi in formato WML, per conformità ad XML, devono obbligatoriamente cominciare con questo preambolo:
<?xml version="1.0">
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
il quale informa che si tratta di un testo XML 1.0, che il tag iniziale
sarà <wml> e che la specificazione ufficiale
del linguaggio si trova all'indirizzo Internet indicato.
Nella prima riga può essere opzionalmente specificato un set di
caratteri per l'interpretazione del testo successivo e questa precisazione
diventa obbligatoria quando il set utilizzato è diverso da UTF-8 o
UTF-16.
Per esempio:
<?xml version="1.0" encoding="ISO-8859-1">Questo modo di procedere permette, ai parser che dovranno interpretare il linguaggio, di avere sempre a disposizione la descrizione sintattica del linguaggio impiegato, anche se si tratta di versioni diverse, e di poter quindi stabilire facilmente se si tratta di un documento ben formato. Qui vediamo il caso di WML in versione 1.1. Si potrebbe pensare che un preambolo di questo tipo introduca un notevole overhead e quindi vada contro le esigenze di risparmiare banda, ma nella versione tokenizzata il tutto viene ridotto ad una decina di bytes. Tale preambolo è utile soprattutto al gateway, il quale ha la responsibilità di verificare la correttezza sintattica del deck e di restituire al browser un messaggio di errore in caso siano rivelati problemi o il testo compattato (e depurato da ogni componente non necessaria per il client) se la verifica è andata a buon fine.
3.3. La struttura del deck
In WML ogni file corrisponde ad un deck, ovvero ad un insieme di
card accompagnate da informazioni aggiuntive. Dopo il preambolo,
il deck deve iniziare con il tag <wml>.
Vediamo la spiegazione dei principali tag indicando soltanto eventuali
attributi diversi da id e class:
<wml> |
racchiude tutto il documento e può contenere soltanto 3 tipi di
oggetti: head,
template,
card.
Può avere un attributo
|
||||||||||||||
<head> |
racchiude una intestazione simile a quella del corrispondente tag HTML
e può contenere qualunque numero di oggetti
meta
e al massimo un oggetto access.
In un deck può esserci al massimo un head e se
c'è non può essere vuoto.
|
||||||||||||||
<meta> |
deve essere vuoto e negli attributi sono specificate meta-informazioni
nella forma di coppie nome/valore, esattamente come per HTML.
Gli attributi possibili sono:
name e http-equiv non possono
essere presenti contemporaneamente e deve essere presente almeno
uno dei due.
|
||||||||||||||
<access> |
deve essere vuoto e permette di specificare una forma di controllo di
accesso. In particolare l'accesso a questo deck è consentito
soltanto seguendo un link che proviene da un altro deck il cui indirizzo
sia consistente con i due attributi:
access
e se non c'è l'accesso è consentito in ogni caso.
|
||||||||||||||
<template> |
racchiude una serie di informazioni che vanno applicate a tutte le
card. In particolare può
contenere oggetti di tipo do e
onevent.
In un deck può esserci al massimo un template.
Tra gli attributi possibili abbiamo
|
||||||||||||||
<card> |
racchiude il testo di una card.
Un deck deve contenerne almeno una.
Tra gli attributi possibili abbiamo:
id di una card è molto importante
perché caricare un URL che termina con
#frammento1
significa visualizzare soltanto la card con
id="frammento".
Se non viene specificato nessun frammento, allora la card
visualizzata sarà la prima (salvo diversamente indicato da
onenterforward e onenterbackward).
|
Un esempio di deck potrebbe essere quindi:
<wml>
<head>
<meta name="author" content="Simone Piunno"/>
</head>
<template onenterforward="#splash" onenterbackward="#main">
<do type="prev" label="Back"><prev/></do>
</template>
<card id="splash" title="wap.chaos.cc" newcontext="true">
<!-- contenuto della prima card -->
</card>
<card id="main" title="wap.chaos.cc/2">
<!-- contenuto della seconda card -->
</card>
</wml>3.4. L'attributo xml:lang
Molti tag di WML possono avere un attributo xml:lang
per specificare il linguaggio naturale o formale utilizzato dall'elemento
o dai suoi attributi.
I valori da utilizzare con xml:lang sono i codici di
lingua specificati in [RFC1766].
Il terminale è tenuto a fare quanto possibile per presentare il
testo in accordo alle specificità della lingua dichiarata.
I tag interni possono ereditare questo attributo da quelli più
esterni. La lingua di un elemento va stabilita in base a questo ordine
di precedenza:
- basandosi sull'attributo
xml:langdichiarato nell'elemento; - basandosi sull'attributo
xml:langdichiarato nel più vicino elemento genitore; - basandosi su informazioni provenienti dalle meta informazioni o dai protocolli di trasporto;
- basandosi sulle impostazioni di default del terminale.
3.5. La struttura della card
Ogni card corrisponde ad un insieme di contenuti e ad
una serie di eventi, in parte ereditati dal
template del deck, in
parte specificati direttamente.
Quando un evento è specificato sia nel
template che nella
card, solo quello nella
card viene preso in considerazione.
I tag che una card può contenere sono:
<p> |
indica un paragrafo e può contenere testo ed oggetti di tipo
em, strong,
b, i,
u, big,
small, br,
img, anchor,
a, table,
input, select,
fieldset e do.
Tra gli attributi possibili abbiamo:
|
||||||||||
<pre> |
indica un paragrafo preformattato.
Il browser dovrebbe visualizzare un paragrafo pre
con un font a spaziatura uniforme, disabilitando il
word-wrapping e lasciando intatti gli spazi multipli.
Può contenere testo e oggetti di tipo
a, br,
i, b,
em,
strong,
input,
select
in numero qualunque. Ha un solo attributo chiamato
|
||||||||||
<do> |
indica la presenza di un qualche meccanismo di interazione con l'utente.
La rappresentazione è dipendente dal browser e l'autore
deve assumere soltanto che il tag do sia associato ad un
unico widget che l'utente possa in qualche modo attivare.
Si potrebbe trattare ad esempio di un soft button.
Quando l'utente attiva un do, il corrispondente
task (esattamente uno per ogni do) viene eseguito.
Ci sono quattro tipi di task rappresentati da altrettanti tag:
go, prev,
noop, refresh.
Il tag do può comparire sia nella
card che nel template.
Tra gli attributi permessi abbiamo:
|
||||||||||
<timer> |
dichiara un timer.
Una card può contenerne al massimo uno e deve essere vuoto.
Tra gli attributi abbiamo:
timer inizia a contare il tempo dal momento in cui la
card è completamente caricata e al suo scadere
scatena un evento ontimer specificato nel tag
onevent o negli attributi del tag
card
o del template.
Il timer viene fermato nel momento in cui si esce dalla
card (anche per un semplice reload).
La risoluzione temporale è dipendente dall'implementazione e
non si può fare affidamento su un determinato livello di
precisione.
|
||||||||||
<onevent> |
connette un task ad un certo evento intrinseco correlato al tag che lo
contiene. L'unico attributo, obbligatorio, è:
go, prev,
noop, refresh.
|
Un esempio di card potrebbe essere:
<card id="main" title="wap.chaos.cc">
<p>
Un testo<br/>
non preformattato
</p>
<pre>
Un testo
preformattato
</pre>
<p>Hai 5 secondi per fare un refresh</p>
<timer name="tempo scaduto" value="50">
<onevent type="ontimer">
<go href="troppotardi.wml">
</onevent>
<do type="accept" label="Refresh"><refresh/></do>
</card>3.6. I Task, l'history e lo shadowing
Le azioni collegabili agli eventi si riducono a 4 tipologie:
<prev> |
Richiede la navigazione all'ultimo indirizzo visitato.
In pratica viene eseguita una operazione di pop
dalla pila dell'history.
Il browser è quindi obbligato a conservare in memoria un
elenco temporale degli indirizzi di tutte le pagine caricate.
Tale elenco viene aggiornato all'atto del caricamento di ogni pagina e
può essere azzerato tramite l'attributo newcontext
della card.
Può contenere oggetti di tipo
setvar.
|
||||||||||
<refresh> |
Richiede il ricaricamento della pagina attuale.
Può contenere oggetti di tipo
setvar.
|
<noop> |
Indica che non deve essere fatto nulla e deve essere vuoto.
È utile solo nel caso si voglia mascherare un task
dichiarato nel template.
|
||||||||
<go> |
Indica un nuovo URI da caricare ed esegue un'operazione di
push sulla pila dell'history.
Tra gli attributi abbiamo:
setvar
e postfield.
|
Una complessa serie di regole viene utilizzata per decidere quando un
task dichiarato all'interno di una card,
maschera un corrispondente task dichiarato nel
template:
- Un elemento per la gestione di eventi definito nella
card, maschera gli elementi dichiarati neltemplateconnessi allo stesso evento (si pensi ad esempio all'attributoonenterforward). - Un tag
oneventdichiarato nellacard, maschera glioneventdichiarati neltemplateche hanno lo stesso attributotype. - Un tag
dodichiarato nella card, maschera i tagdodichiarati neltemplateche hanno lo stesso attributoname. - Gli elementi connessi ad eventi che sono stati mascherati o che
contengono il task
noop, sono considerati non attivi e vengono ignorati.
<postfield> |
Indica una coppia nome/valore da passare come parametro durante il
caricamento di una nuova pagina corrispondente ad un programma
[CGI].
Deve essere vuoto e deve possedere entrambi gli attributi:
|
||||
<setvar> |
Indica una coppia nome/valore da inserire nell'environment durante
l'esecuzione di un task. Deve essere vuoto e possedere entrambi
gli attributi:
|
Esempi di invocazione task:
<do type="accept" label="Ok">
<go href="/cgi-bin/somma.cgi" method="get">
<setvar name="flag" value="1"/>
<postfield name="a" value="4"/>
<postfield name="b" value="6"/>
</go>
</do>
<do type="options" label="Niente"><noop/></do>
<onevent type="ontimer"><refresh/></onevent>
<p>
<anchor>
Torna indietro<prev/>
</anchor>
</p>3.7. I link ipertestuali
Ci sono due modi per indicare un link immerso nel testo di una card:
<anchor> |
indica un pezzo di testo che, se selezionato, provoca l'esecuzione di un
task. Può contenere testo ed oggetti di tipo
br, img,
go, prev,
refresh.
Sebbene possa contenere task di ogni tipo
(tranne noop),
di solito lo si usa in congiunzione con
go per realizzare
di fatto l'equivalente del tag a
(con la differenza che dentro il go
possono esserci dei setvar
e dei postfield).
I suoi attributi sono:
|
||||||||
<a> |
è l'esatto equivalente dell'omonimo in HTML e corrisponde alla
coppia anchor+go
con il go
vuoto, con la differenza che la tokenizzazione di a
è più efficiente.
Può contenere testo e oggetti di tipo br e
img. I suoi attributi sono:
|
Ad esempio:
<anchor>
Premi qui per procedere
<go href="http://wap.chaos.cc/" accesskey="1" title="procedi"/>
</anchor>
<a href="http://wap.chaos.cc/" accesskey="1" title="procedi">
Premi qui per procedere
</a>3.8. Interazione con l'utente
Per interagire con l'utente abbiamo due modi: chiedendo l'inserimento di una stringa o facendo scegliere una possibilità da un elenco predefinito. Ecco come:
<input> |
indica un campo testuale che l'utente può compilare.
format consiste in una maschera che contiene testo
statico visualizzato all'interno del campo e caratteri di controllo che
individuano zone da compilare e tipo di caratteri accettati all'interno di
queste zone. È qualcosa di prossimo ad un'espressione regolare molto
semplificata. Ad esempio un formato "NNNX" accetta
soltanto stringhe composte di 3 cifre e una lettera maiuscola.
*M significa che vengono accettate stringhe contenenti un
numero arbitrario di caratteri qualunque. Ogni tag input crea
automaticamente una variabile di nome name nell'environment,
il cui contenuto è il testo inserito dall'utente.
|
||||||||||||||||||||||
<select> |
Contiene una serie di opzioni specificate da oggetti di tipo
option tra le quali l'utente
può scegliere.
Le opzioni possono essere organizzate in gruppi gerarchici usando
optgroup.
Deve contenere oggetti di tipo option
o optgroup e non può essere
vuoto. Gli attributi permessi sono:
multiple permette che vengano selezionate
più opzioni contemporaneamente, allora value e
ivalue conterranno rispettivamente l'elenco delle opzioni
selezionate separate da punti e virgola e l'elenco degli indici numerici
separati da punto e virgola.
|
||||||||||||||||||||||
<option> |
Contiene una opzione dell'oggetto
select, specificata
attraverso un testo. Può contenere anche oggetti di tipo
onevent.
Gli attributi permessi sono:
|
||||||||||||||||||||||
<optgroup> |
permette all'autore di raggruppare opzioni tra loro correlate formando
una gerarchia. Nell'albero formato, tutte le foglie devono essere di tipo
option (è un errore avere un
tag optgroup
vuoto). Il browser può completamente ignorare questo tag.
Contiene oggetti di tipo optgroup e
option
e gli attributi permessi sono:
|
||||||||||||||||||||||
<fieldset> |
permette di raggruppare oggetti select
e input
insieme a parti di testo in modo che il browser possa ottimizzare la
visualizzazione della card e che
l'autore possa specificare
una relazione logica tra elementi. Il browser può ignorare questo
tag. Può contenere testo ed oggetti di tipo
em,
strong,
b,
i,
u,
big,
small,
br,
img,
anchor,
a,
table,
input,
select,
fieldset,
do.
Può avere gli attributi:
|
Per esempio:
<fieldset title="raccolta dati">
<input type="text" name="nome" format="*A"/>
<select name="claurea" iname="clauridx" multiple="false">
<optgroup title="Ingegneria">
<option value="iele">Ing. Elettronica</option>
<option value="imat">Ing. Materiali</option>
<option value="iciv">Ing. Civile</option>
</optgroup>
<option value="arch" onpick="noning.wml">
Architettura
</option>
</select>
</fieldset>3.9. L'environment e le variabili
WML contiene meccanismi di gestione dello stato del browser ed in particolare
è prevista l'esistenza di una tabella di history e di un dizionario
contenente coppie nome/valore impostabili a runtime.
L'environment viene azzerato ogni volta che il browser entra in una
card che ha l'attributo newcontext settato:
dizionario e history vengono svuotati e ogni altro stato dipendente
dall'implementazione viene riportato ad un valore noto.
Tale operazione è interessante soprattutto sul fronte della sicurezza
e della protezione della privacy perchè assicura che eventuali
informazioni sensibili siano cancellate e non vengano erroneamente usate in
deck diversi da quelli preposti.
Tutto il contenuto di un deck può essere parametrizzato in termini di variabili. Questo significa che quasi in ogni punto del testo, è possibile inserire riferimenti al dizionario, che subiranno a runtime la sostituzione nome->valore. I riferimenti a variabili che non sono state impostate vengono sostituiti dalla stringa nulla. La sostituzione avviene in tutto il testo e in molti attributi dei tag. I riferimenti a variabile possono essere in tre forme:
$nomevariabile$(nomevariabile)$(nomevariabile:tipodiescape)
Il secondo tipo è sempre da preferire al primo perché riduce la
possibilità che si formino situazioni ambigue. Il terzo tipo è
identico al secondo a parte per il fatto che viene specificato un metodo di
escape, ovvero una procedura di conversione del valore della variabile,
da applicarsi a runtime all'atto della sostituzione nome->valore.
Ci sono tre metodi di escape supportati:
noesc, escape, unescape.
Il primo ovviamente significa che nessuna conversione deve essere effettuata
e gli altri due indicano conversioni di andata e ritorno verso il formato
URL-encoded.
Quando il metodo di escape non è specificato esplicitamente, il browser
decide in base a dove la variabile è posizionata e in particolare viene
scelto noesc dappertutto tranne che negli attributi
href dove viene scelto il metodo escape.
La sostituzione inizia immediatamente dopo che è stato completato il
parsing XML e questo implica che tutte le entità
$
e $ vengono trattate esattamente
come se fossero il simbolo
$ che indica un riferimento a variabile.
Per inserire nel testo un simbolo $ senza che venga interpretato
come riferimento a variabile, è necessario raddoppiarlo.
L'inserimento di nuove variabili o la modifica del valore di quelle esistenti
nell'environment può avvenire in diversi modi:
- tramite il tag
setvarall'esecuzione di un taskgo,prevorefresh; - tramite il tag
input, quando l'utente inserisce una stringa; - tramite il tag
select, quando l'utente sceglie una delle opzioni proposte.
Come si nota mancano i costrutti corrispondenti al tag
FORM e all'attributo TYPE="submit"
del tag INPUT di HTML.
L'equivalente di un FORM HTML può però essere
costruito tramite la sostituzione di variabile:
<input type="text" name="nome"/>
<select name="claurea" multiple="false">
<option value="iele">Ing. Elettronica</option>
<option value="imat">Ing. Materiali</option>
<option value="iciv">Ing. Civile</option>
</select>
<anchor>
Procedi
<go href="/cgi-bin/processa.cgi">
<postfield name="nome" value="Sig. $nome"/>
<postfield name="clau" value="$(claurea:noesc)"/>
</go>
</anchor>3.10. Le tabelle
Come in HTML, WML fornisce un metodo per definire tabelle:
<table> |
crea una tabella nella quale ogni cella può contenere testo e immagini.
È compito del browser stabilire il migliore aspetto della tabella,
comprese le larghezze delle colonne, le altezze delle righe, etc.
Gli attributi permessi sono:
C
per centrata, L per allineamento a sinistra,
R per allineamento a destra, D per lasciar
decidere il browser.
Ad esempio con align="LCDDR" diciamo che la
prima colonna va allineata a sinistra, la seconda va centrata, delle
successive due non ci interessa e la quinta va allineata a destra.
Può contenere soltanto oggetti tr e deve
contenerne almeno uno.
|
||||||||
<tr> |
indica una riga della tabella.
Può contenere soltanto oggetti td e deve contenerne
almeno uno. Il browser deve attenersi all'indicazione columns
del tag table qualunque sia il numero di oggetti
td inseriti dentro le righe tr: se il numero dei
td è inferiore al numero di colonne, il browser deve
riempire la riga con celle vuote; se il numero di td è
superiore al numero di colonne, il browser deve accorpare nell'ultima
colonna i td in eccesso.
|
||||||||
<td> |
indica una cella della tabella. Può contenere testo e oggetti di
tipo em,
strong,
b,
i,
u,
big,
small,
br,
img,
anchor,
a.
Può essere vuoto, nel qual caso il browser è tenuto a
visualizzare una cella vuota. L'unico attributo è:
|
Per esempio una tabella potrebbe essere specificata come:
<table columns="2" align="LR">
<tr>
<td>uno</td>
<td>1</td>
</tr>
<tr>
<td>due</td>
<td>2</td>
</tr>
</table>3.11. Il Layout
WML offre una serie di tag utili a definire il layout del
rendering operato dal browser.
I tag seguenti sono tutti opzionali, nel senso che il browser non è
tenuto a supportarli, e possono tutti quanti contenere testo e oggetti di
tipo em,
strong,
b,
i,
u,
big,
small,
br,
img,
anchor,
a,
table.
<em> |
indica che il contenuto deve essere enfatizzato. |
<strong> |
indica che il contenuto deve essere molto enfatizzato. |
<i> |
indica che il contenuto deve essere reso in corsivo. |
<b> |
indica che il contenuto deve essere reso in grassetto. |
<u> |
indica che il contenuto deve essere reso sottolineato. |
<big> |
indica che il contenuto deve essere reso con un font più grande. | <small> |
indica che il contenuto deve essere reso con un font più piccolo. |
Inoltre abbiamo anche il tag br, che deve essere
obbligatoriamente supportato dal browser.
<br> |
indica un ritorno a capo.
In WML come in HTML gli spazi e i ritorni a capo del testo non contano
(tranne dentro il tag pre) e con questo tag possiamo
indicare punti nei quali il browser deve obbligatoriamente andare a
capo. Non ha attributi particolari e deve essere vuoto.
|
Per esempio:
<p>
Normale<br/>
<em>con enfasi</em><br/>
<strong>con molta enfasi</strong><br/>
<i>in corsivo</i><br/>
<b>in grassetto</b><br/>
<u>sottolineato</u><br/>
<big>in grande</big><br/>
<small>in piccolo</small>
</p>3.12. Le immagini
WML prevede che il browser possa visualizzare immagini. L'unico formato supportato è WBMP [WAESP] che attualmente consiste in una semplice bitmap monocromatica nella quale i pixel possono essere soltanto o bianchi o neri e senza nessun metodo di compressione applicato. La specifica WBMP prevede che in futuro possano essere utilizzate altre varianti con maggior numero di colori, compressione, animazione, etc.
<img> |
indica un'immagine che deve essere inclusa nel testo.
Deve essere vuoto. Si possono specificare gli attributi:
|
Per esempio:
<p>
Ecco un'immagine:<br/>
<img src="http://wap.chaos.cc/logo.wbmp" alt="[logo]"/>
</p>3.13. Le character entities e le sezioni CDATA
Si presenta spesso il problema di inserire in un testo un carattere che
non ha una rappresentazioni sulla nostra tastiera o nel nostro set di
caratteri. WML adotta il set di caratteri
[ISO10646], anche noto come
[UNICODE].
Nel caso il nostro editor non ci permetta di scrivere alcuni caratteri
di questo set molto ampio, possiamo ricorrere alle character
entities ovvero a simboli del tipo &#N;
o &#xN; dove la N sta rispettivamente per un numero
decimale o esadecimale che va usato come indice nella tabella
[ISO10646].
Così ad esempio i simboli B o
B indicano entrambi una B maiuscola.
Lo stesso meccanismo può essere utilizzato per indicare caratteri
che hanno un significato particolare nel linguaggio utilizzato e che quindi
rischierebbero di essere confusi.
Ad esempio il simbolo < indica l'inizio di un tag.
Per risolvere questo problema sono definite alcune entity aggiuntive:
" indica le virgolette doppie,
" indica la e commerciale,
' indica la virgoletta singola,
< indica il simbolo di minore,
> indica il simbolo di maggiore,
indica uno spazio significativo (non collassabile) e
­ indica un punto nel quale una parola può essere
spezzata per andare a capo.
A volte risulta molto comodo indicare che intere sezioni del testo devono
essere lasciate inalterate, nel senso che al loro interno non deve essere
effettuata la ricerca dei tag nè nessun altro tipo di interpretazione.
In questo caso possiamo isolare la porzione di testo all'interno di un
blocco che inizia con <![CDATA[ e termina con
]]>.
Ad esempio:
Questo è un test <B>
<![CDATA[Questo è un test <B>]]>3.14. La forma codificata e i profili hardware.
Il testo WML viene prelevato sul server di origine nella forma fin
qui descritta e subisce una tokenizzazione da parte del gateway.
Quello che giunge al browser WAP è quindi un file di tipo WMLC
nel quale ogni tag ed ogni suo attributo vengono convertiti in una
rappresentazione binaria tramite tabelle di corrispondenza.
Per esempio il tag <anchor> viene convertito nel
numero esadecimale 22 e l'attributo
type="onenterforward" diventa il numero
3D.
Durante la fase di richiesta, il terminale WAP comunica negli header
[WSP] una serie di parametri specifici
della propria implementazione: Accept,
Accept-Language, Accept-Charset ed un URL
corrispondente ad un file fornito dal produttore e contenente un
profilo completo delle capacità fornite.
In questo modo il gateway ha la possibilità di adattare il
contenuto e di eliminare quelle parti che non sarebbero visualizzabili.
Parte di queste informazioni, quando applicabili anche ad HTTP, viene
comunicata anche al server di origine.
Uno degli header potrebbe apparire ad esempio così:
Accept: application/x-wap.wmlc;
uaprof=http://www.vendor.com/profilo_tel1Questo modo di procedere permette una drastica riduzione dello spazio ed una contemporanea semplificazione nel procedimento di interpretazione che deve essere operato dal browser. L'operazione viene eseguita a livello del gateway perchè questo è il punto nel quale la banda disponibile si restringe. I parametri che possono essere comunicati nel profilo fornito dal produttore sono ad esempio: il set di caratteri, la lingua, i formati e le codifiche supportati, il numero di versione della specifica WML supportata, quello di WMLScript e di WTA, le eventuali librerie WMLScript implementate, etc.
In figura vediamo un disegno chiarificatore di come la tokenizzazione e le altre tecniche di filtraggio permettano di compensare il collo di bottiglia necessari amente presente a livello del gateway.
Note:
1. Per frammento in un URL si intende la parte a destra del simbolo
#.