|
LINGUAGGIO X+V
di Salvatore Zita
Un' applicazione X+V di esempio.
Questa applicazione è un classico sondaggio realizzato attraverso un form da riempire. L’accesso multimodale al form permette di poter interagire
con l’applicazione sia con il mouse che con la voce e rispondere alle domande poste con tecniche di accesso complementari.
L’applicazione è stata realizzata utilizzando lo strumento di sviluppo IBM Rational Software Development Platform integrato con il Multimodal Toolkit
versione 4.1.4.
Il file così realizzato (con estensione .mxml) puo’ girare sui normali browser xhtml e in tal caso l’utente può interagire
solo attraverso le normali tecniche di interazione, oppure su di un browser multimodale in grado di interpretare sia la parte
XHTML sia quella in VoiceXML e in questa circostanza l’interazione è multimodale. Il browser utilizzato per testare l’applicazione
è stato Opera versione 7.55 incluso nel pacchetto multimodal toolkit già citato. Tale browser attualmente supporta soltanto un
TTS e un ASR in lingua inglese. Ciò significa sostanzialmente che il browser può parlare solo l’inglese.
Di seguito verranno descritte le singole parti che costituiscono l’applicazione.
Nel linguaggio X+V il lingguaggio che ospita è l’XHTML pertanto l’intestazione di ogni applicazione è simile a quella che si
trova in una normale pagina XHTML o XML in genere.
Ecco un esempio di come si presentano in genere le prime righe di codice di una applicazione X+V:
La prima riga di codice inserita è la dichiarazione XML, segue la dichiarazione del DOCTYPE; questa ha l’identificatore
PUBLIC quindi bisogna far riferimento alla DTD all’indirizzo:
http://www.voicexml.org/specs/multimodal/x+v/12/dtd/xhtml+voice12.dtd.
L’elemento radice dell’intera applicazione è l’elemento <html> che contiene gli attributi per la dichiarazione dei namespaces.
La prima dichiarazione è quella per il linguaggio XHTML che è assunto come namespace di default seguono le dichiarazioni dei
namespaces riguardanti gli altri linguaggi o moduli utilizzati nell’applicazione.
L’intestazione dei file html è usata anche qui con il medesimo scopo. In particolare in X+V il tag <head> diventa il contenitore di
tutta quella che è la parte vocale del progetto, ossia quella scritta nel linguaggio VoiceXML, assieme alla parte di sincronizzazione.
Questa è quella che non viene interpretata nel caso si utilizzi un browser non multimodale che interpreta solo la parte di codice
scritta in xhtml. La chiusura del tag indica quindi, implicitamente, l’inizio della parte visuale in xhtml.
Il tag <title> funziona come in un normale documento html in pratica serve a dare un titolo all’applicazione. Titolo che verrà mostrato
in cima alla finestra del browser.
La parte vocale può essere composta di tutti gli elementi presenti nel modulo vxml indicato nel namespace. Tutti questi dovranno
essere preceduti dal prefisso vxml: in accordo con la dichiarazione del namespace.
In questa applicazione la parte vocale è tutta contenuta in un unico elemento <form>, ma è ovvio che questa scelta può variare a seconda
delle necessità del programmatore ed è quindi possibile anche l’inserimento di più elementi <form> indipendenti.
Usualmente si preferisce utilizzare lo schema con un unico elemento <form> e un insieme di campi <filed> quando vi è la necessità di dover
sincronizzare la parte vocale con quella visiva. Quando invece è un evento ben definito ad attivare la parte vocale, conviene utilizzare
tanti elementi <form> indipendenti che poi potranno essere richiamati ad arte attraverso un handler.
Nell’applicazione in questione l’evento di load, che si ha al caricamento della pagina nel browser, attiva l’unico elemento <form> presente cioè fa
saltare il FIA ad interpretare la parte vocale.
Una volta “entrati” nel form il browser legge il contenuto dell’elemento <block> ovvero esegue un file audio pre-registrato.
Il form contiene tutti gli elementi field ognuno dei quali riguarda un campo che l’utente è chiamato a riempire. L’attributo xv:id è
un attributo appartenente al modulo per la sincronizzazione (ecco perchè ha il prefisso xv: ), in particolare esso serve a dare un
identificatore univoco necessario per sincronizzare la parte vocale con la parte visuale.
La prima cosa da fare quando si mette l‘utente di fronte ad una scelta è la definizione di una grammatica, ossia di un dizionario delle
possibili parole o frasi che possono essere pronunciate dall’utente e ben interpretate dalla macchina. Le grammatiche possono essere scritte
in più linguaggi in parte equivalenti; quello standard a cui fa riferimento il consorzio W3C è il linguaggio SRGS, un altro forse più
immediato, ma con le stesse potenzialità è JSGF. E’ possibile realizzare grammatiche esterne scrivendole in file indipendenti dall’applicazione
multimodale e poi richiamarle attraverso l’attributo src nell’elemento <grammar>. Al contrario grammatiche meno articolate possono essere
sviluppate nello stesso file mxml all’interno dell’elemento <grammar>.
Nell’esempio mostrato c’e un commento di com’è possibile richiamare grammatiche esterne, tuttavia si è scelto di utilizzare grammatiche interne.
L’elemento <prompt>, figlio di <field>, svolge la stessa funzione di <block> in <form>: il browser legge ciò che è contenuto
al loro interno.
L’elemento <catch> correlato dell’attributo event serve per definire un’azione che l’interprete deve compiere al verificarsi dell’evento specificato.
Nell’ esempio mostrato gli eventi sono:
help che accade quando l’utente pronuncia la parola help durante l’esecuzione dell’applicazione;
nomatch che accade quando l’utente da una risposta che non è tra quelle possibili ovvero tra quelle definite nella grammatica;
noinput che si verifica quando l’utente non da alcuna risposta, o nessuna risposta viene ascoltata dal browser.
L’attributo count serve a differenziare il contenuto di <catch> se gli stessi eventi si ripetono più volte, ad esempio se l’evento noinput si verifica
due volte di seguito la prima volta il browser chiederà all’utente di rispondere alla domanda, la seconda volta elencherà alcune possibili scelte.
L’elemento field nell’applicazione in analisi viene utilizzato ogni volta che c’è una domanda a cui l’utente può rispondere in maniera
complementare vale a dire sia con il mouse sia con la voce. Tuttavia la struttura dell’elemento, ovvero gli elementi in esso compresi,
non varia per nulla o varia di molto poco.
E’ comunque bene fare alcune precisazioni.
Nella situazione in cui l’utente ha la possibilità di rispondere alla stessa domanda in maniera diversa, in altre parole se può dare attraverso
la voce lo stesso input in maniera differente, va usata una particolare sintassi. Ad esempio nella grammatica riportata sopra l’utente può
rispondere alla domanda sullo stato civile widow oppure widower a seconda del proprio sesso. E’ ovvio che il risultato deve comunque essere lo
stesso cioè la variabile riferita allo stato civile deve essere riempita con lo stesso valore sia che si tratti di un uomo che se si tratti di
una donna.
La sintassi utilizzata è : widower{$=widow} che significa: se l’utente risponde pronunciando la parola widower la variabile di pertinenza andrà
riempita con il valore widow.
In una circostanza monomodale questo artificio non ha molto senso, ma è necessario in ambito multimodale per far avvenire in maniera corretta
la sincronizzazione tra parte vocale e parte visuale: visto che non c’è distinzione tra le due scelte nella parte xhtml (abbiamo un solo radio
button sia per la scelta widow che per widower) non deve essercene nemmeno nella parte vxml.
Va ancora precisato che la grammatica mostrata in figura si presenta così semplice perchè l’input è costituito da una sola variabile. Ovviamente
è possibile gestire anche casi più complessi in cui l’elemento field è riempito con un vettore di variabili, ciò accade se si possono fare più
scelte per una stessa domanda. In tal caso la grammatica va integrata con la definizione di un vettore che viene costruito con le varie scelte.
La sintassi utilizzata a tal uopo può essere la seguente:
Una volta completata la parte vocale, cioè chiuso l’ultimo elemento <form> aperto precedentmente vi è la parte di sincronizzazione vera e
propria.
L’elemento di sincronizzazione è <sync> ed appartiene al modulo di sincronizzazione che nella definizione dei namespaces è stato indicato
con il valore xv .
Ecco un esempio dell’utilizzo dell’elemento in questione:
L’elemento sync nell’esempio ha due attributi. L’attributo input vuole il nome (name) dell’elemento <input>, della parte in html, che deve essere
sincronizzata; l’attributo field va completato con il nome dato a xv:id=”” nel campo field della parte vocale corrispondente. In poche parole
per eseguire la sincronizzazione delle due modalità d’interazione c’è bisogno che queste vengano identificate: xv:input=”” serve ad indentificare
la parte visuale in html, xv:field=”” serve invece per indicare la parte vocale in vxml.
La chiusura dell’elemento <head> indica l’inizio della parte visuale in html.
Poiché il namespace di default è proprio quello relativo al linguaggio xhtml e quindi questo ospita tutti gli altri linguaggi, è possibile
scrivere la parte visuale come se si stesse realizzando una normale applicazione in xhtml. Gli elementi e gli attributi sono sostanzialmente gli
stessi, ma bisogna sempre aggiungere a questi gli strumenti necessari al collegamento tra i vari linguaggi.
E’ possibile collegare i due linguaggi attraverso l’utilizzo di eventi ed handler oppure attraverso la sincronizzazione delle variabili di input.
Nel primo caso basta inserire in un elemento xhtml degli attributi del modulo XMLEvents:
In questo caso l’elemento body, che segna l’inizio della parte xhtml, contiene un attributo event del modulo xml-events settato a “load” e un
handler che indica l’identificativo del form a cui “saltare” nel caso l’evento si verifichi. Il risultato di questa riga di codice è che appena
viene caricata la applicazione su di un browser, cioè si verifica un evento di load, il FIA passa ad interpretare il form indicato nell’attributo
handler, cioè dalla parte visuale si passa a quella vocale.
Nel secondo caso, quello della sincronizzazione, bisogna stare attenti ai nomi e ai valori che vengono inseriti nel campo input:
Nell’esempio mostrato gli attributi dell’elemento <input> sono:
“type” indica il tipo di input che andrà visualizato a schermo,
“value” indica il valore che conterrà la variabile input se quel tipo di input è selezionato dall’utente.
Nel caso di sincronizzazione multimodale tale valore dovrà corrispondere a quello della relativa parte vocale: nell’esempio mostrato se alla
voce Profession l’attributo value è settato a housewife, l’utente che vuole rispondere a quella domanda con la voce deve pronunciare la parola
housewife o comunque una parola che restituisca il valore housewife. Sostanzialmente tutti gli attributi value degli input relativi ad una
stessa domanda devono corrispondere alla grammatica della corrispondente parte vocale.
“name” è il nome che viene dato all’elemento <input> necessario alla sua individuazione ai fini della sincronizzazione. E’ importante che
ad una domanda con più risposte possibili il valore name sia settato allo stesso valore per tutte le possibili risposte in modo che tutte le
risposte ad una domanda siano sincronizzate con la stessa parte vocale. Il valore dell’attributo name è quello che va inserito nel campo xv:input
dell’ elemento <sync>.
Clicca qui per scaricare l'applicazione
multimodale con estensione .mxml da poter testare con un browser multimodale.
Torna al primo articolo sul linguaggio X+V di Salvatore Zita.
|
